newforms widget for autocompleting text fields using jquery autocomplete plugin: http://jquery.bassistance.de/autocomplete/ to be implemented: - store the pk value into an hidden field - handling ChoiceFields and many others massimo dot scamarcia at gmail.com
I love newforms. But sometimes using ``{{ form }}`` within a template doesn't give you enough flexibility. The other option, manually defining the markup for each field, is tedious, boring and error-prone. This is an example of how you can use a template filter to get the best of both worlds. Use it like this to render an entire form: ``{% for field in form %}`` {{ field|form_row }} ``{% endfor %}`` Or use it on a per-field basis: ``<fieldset>`` {{ form.first_name|form_row }} {{ form.last_name|form_row }} ``</fieldset>``
This function emulates the file upload behaviour of django's admin, but can be used in any view. It takes a list of POST keys that represent uploaded files, and saves the files into a date-formatted directory in the same manner as a `FileField`'s `upload_to` argument.
Django's transition from oldforms to newforms is nearing. If you're using recent trunk source code from Django's subversion repository, you should start using newforms. But there are still some rough edges as of today. File uploading seems to be one of them. (Adrian and other Django folks are well aware of this. Please don't bother them by asking "Are we there yet?") The Django mailing lists and Google searching didn't turn up any best practices for this area of newforms, so I muddled through it and here's the result. I omit the urls.py code necessary to hook up the zip_upload method to a URL, but otherwise this should be complete. And if I haven't loaded this with enough caveats...please be aware this code may be obsoleted soon.
Nicely output all form errors in one block, using field labels rather than the field attribute names.
Sometimes the only way to reproduce a bug on a production site is to login as the User who encountered it. This form allows you to login as any user on the site. **Usage** @staff_member_required def login_as(request, template="login_as.html"): data = request.POST or None form = LoginAsForm(data, request=request) if form.is_valid() form.save() return HttpResponseRedirect(settings.LOGIN_REDIRECT_URL) ...
If you're like me, you've got a models with a lot of fields/foreignkeys and often only want to edit a portion of the model in a form. Add this method to your custom form class and use it in place of the save() method.
A very common field in forms is the `<textarea>`, but `newforms` has no such field. Instead, you must use a dummy field (such as `newforms.CharField`) and use the `newforms.widgets.Textarea()` widget to render a textarea.
Daniel Roseman's snippet, updated will all fixes mentioned in the comments of the first version + some other things to make it work under Django 1.4. South, and dumpdata are working. There's an ugly int(....) at the validate function in order to cast each value as an integer before comparing it to default choices : I needed this, but if you're storing strings values, just remove the int(......) wrapper. ------------------------------------- Orginal readme Usually you want to store multiple choices as a manytomany link to another table. Sometimes however it is useful to store them in the model itself. This field implements a model field and an accompanying formfield to store multiple choices as a comma-separated list of values, using the normal CHOICES attribute. You'll need to set maxlength long enough to cope with the maximum number of choices, plus a comma for each. The normal get_FOO_display() method returns a comma-delimited string of the expanded values of the selected choices. The formfield takes an optional max_choices parameter to validate a maximum number of choices.
Using this method you can combine form for standart django.contrib.auth.models.User model and for your project profile model. As now, ProfileForm can be used as usual, and it will also contain UserForm fields.
Syntax: `{% get_fieldset list,of,fields as new_form_object from original_form %}` Example: {% load fieldsets %} ... <fieldset id="contact_details"> <legend>Contact details</legend> <ul> {% get_fieldset first_name,last_name,email,cell_phone as personal_fields from form %} {{ personal_fields.as_ul }} </ul> </fieldset> <fieldset> <legend>Address details</legend> <ul> {% get_fieldset street_address,post_code,city as address_fields from form %} {{ address_fields.as_ul }} </ul> </fieldset>
Django administration provides three buttons for submitting the currently edited object. Each of them has a unique name and depending on the name that is sent to the server, the specific action is performed. I see this as an ugly solution and prefer to have a choice field in the form which would render as submit buttons with different values. Then the values would be checked instead of the names. Therefore, I created the `MultipleSubmitButton` widget. When `<input type="submit" value="Go" />` is used, the value sent to the server always matches the text on the button, but if `<button type="submit" value="go">Go</button>`, the value and the human representation might differ. To use the `MultipleSubmitButton` widget, pass it to the widget parameter of a `ChoiceField` like this: SUBMIT_CHOICES = ( ('save', _("Save")), ('save-add', _("Save and Add Another")), ) class TestForm(forms.Form): do = forms.ChoiceField( widget=MultipleSubmitButton, choices=SUBMIT_CHOICES, ) When you print `{{ form.do }}` in the template, the following HTML will be rendered: <ul> <li><button type="submit" name="do" value="save">Save</button></li> <li><button type="submit" name="do" value="save-add">Save and Add Another</button></li> </ul> When you submit this form and check the validity of it, `form.cleaned_data['do']` will return "save" or "save-add" depending on the submit button clicked.
I will change a model form widget attribute without define the complete field. Because many "meta" information are defined in the model (e.g. the help_text) and i don't want to repeat this. I found a solution: Add/change the widget attribute in the __init__, see example code.
the trick resides in `field.field.required`. The intuitive way of testing this in the templates is to access `field.required`. But it's not the good one. Enjoy! [Found via Django users Google Groups](http://groups.google.com/group/django-users/browse_thread/thread/ce83f74fb1156b4b/0df36947de16a071?lnk=gst&q=required+field#0df36947de16a071)
Here is a way to get a drop down list from a queryset, with a list of "featured" items appearing at the top (from another queryset). This can be used for long select boxes which have a subset of commonly used values. The empty label is used as a separator and values can appear in both the featured set and the full set (it's more usable if they are in both). For example a country drop down list with 5 featured countries might look like this: Andorra Australia Kazakhstan Singapore Turkey ------------ Afghanistan Albania Algeria American Samoa Andorra Angola (hundreds more) To use this, define your form field like this: country = FeaturedModelChoiceField(queryset=Country.objects.all(), featured_queryset=Country.objects.featured())