On Jul 12, 8:12 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson <ean...@gmail.com> wrote:
> > Good proposal overall. One thought I have in order to try and combat
> > the massive parameter list of {% form %} is to optionally add an
> > ending tag, as well as sub-tags:
>
> > {% form myform %}
> >    {% using birthday=calendar %}
> >    {% renderer "as_ul" %}
> >    {% autocomplete "name_autocomplete" %}
> >    {% doctype xhtml1 %}
> > {% endform %}

In django-uni-form (http://github.com/pydanny/django-uni-form) we pass
into the form tag a 'form helper' object that contains attributes as a
parameter. This means that assembling the special qualities of the
form can happen in the view.py or forms.py.

helper = FormHelper()
helper.use_csrf_protection = True

{% uni_form myform helper %}

This approach has been popular in the community that uses django-uni-
form although mostly it is used to add buttons and layout options that
come in django-uni-form. People do really complex forms using the
layout extension of the project (especially using BartTC's Layout
module).

Its possible to extend this approach to include other options and
capabilities and work that into the proposed forms changes:

helper = FormHelper()
helper.doctype = 'xhtml1'
helper.use_csrf_protection = True

{% form myform helper %}
  {% form myform errors %}
  {% form myform hidden %}
  {% form myform field name using autocomplete:"name_autocomplete" %}
  {% form myform field birthdate using calendar important %}
{% endform  %}

I'm not sure this is the right way to do things here. The FormHelper
object as implemented needs to be controlled outside the templates.
Which possibly defeats some of Russ' goals in this effort. Also, from
experience, when people put a lot of functionality in the FormHelper
object (django-uni-form's Layout module comes to mind), it means that
the layout controls are in view.py, not in the template. Which
arguably means that the controls are out of the hands of the designer
and in the hands of the developer.

Until I get around to refactoring django-uni-form,

Daniel Greenfeld
pydanny.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to