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
WTForm is an extension to the django newforms library allowing the developer, in a very flexible way, to layout the form fields using fieldsets and columns WTForm was built with the well-documented [YUI Grid CSS](http://developer.yahoo.com/yui/grids/) in mind when rendering the columns and fields. This should make it easy to implement WTForm in your own applications. Here is an image of an [example form rendered with WTForm](http://www.gmta.info/files/wtform.png).
I recently worked on an application, where I had to provide a way for users to search for objects based on user-defined properties attached to these objects. I decided to model the search form using a formset, and I thought it'd be a good idea to allow users dynamically add and remove search criteria. The script (dynamic-formset.js) should be re-usable as-is: 1. Include it in your template (don't forget to include jquery.js first!). 2. Apply the 'dynamic-form' class to the container for each form instance (in this example, the 'tr'). 3. Handle the 'click' event for your `add` and `delete` buttons. Call the `addForm` and `deleteForm` functions respectively, passing each function a reference to the button raising the event, and the formset prefix. That's about it. In your view, you can instantiate the formset, and access your forms as usual.
This is an excerpt from the form code used on this site; the tricky bit here is making the `choices` for the `language` field get filled in dynamically from `Language.objects.all()` on each form instantiation, so that new languages can be picked up automatically. It also adds a blank choice at the beginning so that users can't accidentally ignore the field and incorrectly end up with whatever Language was first in the list. If you use this, always remember that you have to call the superclass `__init__` _before_ you set your dynamic choices, and that you need to accept `*args` and `**kwargs` so you can pass them to it. In theory, `ModelChoiceField` will solve this, but it still seems to be a bit buggy.
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>``
Renders an select field with some optgroups. Some options can be outside the optgroup(s). The options and labels should be in a tuple with ((label, choices),) where choices is a tuple ((key, value), (key2, value2)). If a label is null or blank, the options will not belong to an opt group.
A simple login form that does the actual authentification itself. **Usage:** if request.method == "POST": loginform = LoginForm(request.POST) if loginform.login(): return HttpResponseRedirect(redir_url) else: loginform = LoginForm()
This snippets provide username availability, double email and password validation. You can use it this way : f = SignupForm(request.POST) f.is_valid()
This is a multi file upload widget. That does not require adding multiple file input fields. It requires jQuery.MultiUpload (http://www.fyneworks.com/jquery/multiple-file-upload/)
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.
See the description in the blog entry at [http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/](http://sciyoshi.com/blog/2008/aug/27/using-akismet-djangos-new-comments-framework/)
These three classes allows you to use enumerations (choices) in more natural model-like style. You haven't to use any magic numbers to set/get field value. And if you would like to make your enumeration a full-fledged django-model, migration should be easy. Note, that you can subclass Item to add some context-specific attributes to it, such as `get_absolute_url()` method for instance. Examples are provided in the form of `doctest` in the second half of the snippet.
From [here](http://gacha.id.lv/blog/26/01/2007/django-autocompletefield/) with litle improvements. [More about Script.aculo.us and Django](http://wiki.script.aculo.us/scriptaculous/show/IntegrationWithDjango)
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.
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.