On Mon, Jul 12, 2010 at 3:11 PM, mattimust...@gmail.com
<mattimust...@gmail.com> wrote:
>
>
> On Jul 12, 12:31 pm, 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 %}
>>
>
> I'm +1 on Russell's proposal in general but I'm also -1 on the big
> parameter list to the proposed {% form %} tag.

Ok - we must have different measures for what constitutes a "long
parameter list". As I noted in my response to Tim, there's exactly 1
redundant word in the template tag I've proposed.

The only other way I can think of to shorten the argument list is to
introduce different tags for rendering a single field, rendering
top-of-form field errors, and rendering javascript triggers; so:

{% form myform %} -- would render an entire form

but rolling out the full form manually would require:

{% form_errors myform %}
{% form_field myform.name using autocomplete:"name_ajax" %}
{% form_field myform.email %}
{% form_field myform.birthdate using calendar %}
{% form_triggers %}

To me, this just means a bunch more underscores in templates, and 3
extra tags to register (along with finding a way to share the form row
rendering logic between the {% form %} tag and the other tags.

> Having written some
> complex form field rendering tags for extjs/sencha I can say that
> without some kind of built-in *args/**kwargs-like parameter handling
> for template tags, then having more than a handful of parameters gets
> long and messy quickly.

I'll concede args/kwargs handling in template arguments isn't pretty.
My counterargument would be that I don't see the use case for lots of
argument and kwargs to chrome. "Use this calendar", or "show this
decoration", not "here are 5 different arguments to configure how this
chrome will operate".

The one use case I can think of for chrome arguments is to provide the
named URL for AJAX callbacks. However, this may just be a case of me
not being imaginative enough. If you can provide a use case, I'll
happily reconsider my position.

> Also, it doesn't make your tag that user
> friendly either when they have to keep referring to the docs to figure
> out how to use it.
>
> Andre's idea is interesting and is certainly more readable.

I'm having difficulty reconciling these two positions. My template tag
is too complex because it requires you to remember the idiom FORM X
FIELD Y USING Z; but a nested tag structure with 4 different subtags
is more readable and won't require reference to documentation to
understand how and when to use each subtag?

Yours,
Russ Magee %-)

-- 
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