Initial values for new items in admin
Example: class NewsAdmin(InitialFieldsMixin, admin.ModelAdmin): initial = {'author_name': lambda self, request, obj, **kwargs: request.user}
- admin
Example: class NewsAdmin(InitialFieldsMixin, admin.ModelAdmin): initial = {'author_name': lambda self, request, obj, **kwargs: request.user}
In Django humanize naturalday filter, you could not get the time part since a programming issue, If you apply it like: {% load humanize %} {{ response.date_submitted|naturalday:"Y/n/j H:i" }} You can get 'today', 'yesterday', 'tomorrow' or empty, but you can not get such as '2009/9/10 11:56' So I change it like above code. Now you can get 'today', 'yesterday', 'tomorrow' or '2009/9/10 11:56'
it works like an original "pluralize" filter, but it need argument with 3 parts, splitted by comma.
Adds http://hostname or https://hostname before every URL generated by a Django url function. **Example:** Normally, something like YourModel().get_absolute_url() would return `/2009/09/02/slug`. However, this is not an absolute URL, because it does not include an HTTP schema or host. With this middleware, YourModel().get_absolute_url() will return `http://yourdomain.com/2009/09/02/slug`. This will also work for calls to reverse() or the {% url %} template tag. **Installation:** Drop this code into yourproject/middleware/scriptprefix.py. **Usage:** In your settings.py, add: MIDDLEWARE_CLASSES = ( # ... 'yourproject.middleware.scriptprefix.ScriptPrefixMiddleware', # ... )
A formset class where you can add forms as you discover the need within your code. There is also the ability to add ManagmentForm fields. If you ever found yourself in a situation where 1) you have repeated forms that need to be displayed in different locations, or 2) if you find the application logic works better if you add forms as you discover you need them, this code will help you out. Below is pseudo code based on a real implementation I used. Each form had a save button and the SELECTED_PAYMENT field was set through JavaScript. It is very difficult to use JavaScript with repeated forms, without using a formset. from myProject.myApp import myFormsUtils from myProject.myApp.forms import PaymentForm SELECTED_PAYMENT = 'SELECTED_PAYMENT' # extra_fields format: {Field name: (Field type, Initial value)} l_extra_fields = {SELECTED_PAYMENT: (forms.IntegerField, -1)} PaymentFormSetType = myFormsUtils.formset_factory(PaymentForm, extra=0, extra_fields=l_extra_fields) if request.method == 'POST': paymentFormSet = PaymentFormSetType(data=request.POST) if paymentFormSet.is_valid(): li_curFormIdx = pagaFormSet.management_form.cleaned_data[SELECTED_PAYMENT] paymntForm = paymentFormSet.forms[li_curFormIdx] ... do stuff ... # To generate the formset paymentFormSet = PagamentoFormSetType() # You can re-add a form retrieved (as in the one above) l_form = paymentFormSet.add_form(paymntForm) # Or use the add function just like creating a new form l_form = paymentFormSet.add_form(personID=argPersonID, propID=argPropID, year=argYr, amt=lc_Amt) I then stored the `l_form` variables above directly into a unique Context structure and displayed them each individually in my template. Of course this also meant that I also had to output the `paymentFormSet.management_form` explicitly within my template. EDIT 09-11-2009: Modified the initial_form_count() method to properly handle initial form values in conjunction with dynamically added forms.
Widget for TinyMCE 3.2.6, a WYSIWYG HTML editor for `textarea`. **Note:** > This snippet uses the TinyMCE package thats contains special jQuery build of TinyMCE and a jQuery integration plugin. Anyway, is easily to adapt to standard package. Usage example: from django.contrib.flatpages.admin import FlatpageForm class MyFlatPageForm(FlatpageForm): content = forms.CharField(widget=TinyMCEEditor()) [TinyMCE download page](http://tinymce.moxiecode.com/download.php)
This will reload the translation file for every request if you add it as a middleware in settings.MIDDLEWARE_CLASSES.
I recently had a need to build an iTunes style filtered search -- a user can add/subtract any number of filters whereby the are offered selects for fields they want to search, what type of search they wish to perform on that field (i.e., equals, contains, etc.), and then enter a value to search. Finally, they are provided the option to search all or any of the created filters. To keep things simple, I created this dynamic query builder. It takes a Model, plus lists of fields, types, values, and the chosen operator (and/or). Then, it constructs actual Q objects for each, performing a small sanity check to ensure a blank value has not been passed in. In the end, it returns either a filtered QuerySet or an empty result set to ensure that we can at least provide a message back to the user if nothing comes of trying to build the query. One would use it like so: results = dynamic_query(ModelName, fields_list, types_list, values_list, operator) if results: # do something else: # do something else
This is an adaption of [django.forms.extras.widgets.SelectDateWidget](http://code.djangoproject.com/browser/django/trunk/django/forms/extras/widgets.py#L16) which has no day dropdown - it still produces a date but with the day set to 1. Example use class myForm(forms.Form): # ... date = forms.DateField( required=False, widget=MonthYearWidget(years=xrange(2004,2010)) )
Django's standard inclusion_tag doesn't include context variables by default. When you add takes_context you are required to manually merge the context variables into the dict which your tag returns, which tends to result in wasteful code or [possibly accidentally] leaking variables into the global context (`context.update({…})`). This decorator allows your inclusion tag to remain simple and still have safe access to the global context for things like `MEDIA_URL`: @register.inclusion_tag('my_template') @private_context def my_tag(context, …): return {"foo": 1, "bar": 2}
A simple context_processor to include location info. Useful for permalinks, site name references, and navigation bars. For example: {% if location.path|match:"/$" %} class="current"{% endif %} See also my [match filter](/snippets/1686/).
At WWU Housing, we started using the [Tempest jQuery plugin](http://plugins.jquery.com/project/tempest) for javascript templating, which has the same {{ var }} syntax as Django's templating. We wanted to be able to use the same templates in our server-side python and our client-side js, so we had to have a way of including the unrendered template for the js. At the same time, for convenience, it had to be modular so we could push the same code from our dev- to our live-server and not worry about absolute paths (which is why the {% ssi %} tag did not work). So the {% include_raw %} tag was born.
See docstring
See docstring
This is a username field that matches (and slightly tightens) the constraints on usernames in Django's `User` model. Most people use RegexField, which is totally fine -- but it can't provide the fine-grained and user friendly messages that come from this field.
3110 snippets posted so far.