On Tuesday, June 28, 2011 11:56:41 PM UTC+12, Gregor Müllegger wrote:
>
> However I think these templatetags could go into a thirdparty app.
>
-0, changing a label / help text at least are pretty common cases - the
template designer shouldn't be at the mercy of the python form settings.
I'm glad that you've thought about this a bit though and agree that just
getting something working is better than trying to fix all the problems at
once.
> BTW: even without the thirdparty apps it's already possible to change the
> label for a field in an (somehow) easy way. Just extend from the row
> template
> you use for your other rows in the form and override the {% block label %}.
>
A passing thought is that I wonder if we allow for this inline too, like how
{% form using %} works...
> How are HTML classes specified for rows which are required / contain
> errors?
>
> > (and one more slightly obscure one, probably out of scope...)
>
> This can be achieved in the row template:
>
> <div{% if field.errors %} class="errors"{% endif %}>
>
Can't a row technically have more than one field though? I guess it's still
solvable with a custom template filter or the like, just seems like another
common case we could account for with some context var passed to the row
template.
> > How does the form in python have knowledge of the widget which the field
> was
>
> > rendered with as picked by the template?
> > This is critical since building the form's data requires using the
> widget's
> > value_from_datadict.
>
> I think thats conceptually not possible. We simply can change the widget
> during
> template rendering time, which makes it impossible to decide in the python
> code with which widget we end up. And theoretically we could even render
> the
> form twice with different widgets. Or throw the rendered template away
> without
> using the widget at all.
>
In this case, why do we even have this format: {% formconfig widget
widgets.Textarea for "comment" %} and the terminology of widgets?
It seems like that should really just boil down to {% formconfig field using
"some/textarea.html" for "comment" %} and just referring to fields only. A
widget to me encompasses the backend logic of decoding the data, etc.
I think it'd be a great plus if we *could* make it work for different
widgets. This would really give power to change forms dynamically at the
template layer.
I remember thinking a while ago about some kind of widget repository
available to the templates, combined with a hidden input per field that
could notify the python form of the alternate widget used (the hidden input
only used if the widget differed than the default for that field). This
would allow for the same form to be used with different templates which used
completely different widgets.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/ZKI7d8x1WbIJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
