Hi Chris,
2011/6/29 Chris Beaven <smileych...@gmail.com>:
>>
>> 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.
So I spoke to Carl yesterday about some of the ideas you brought up and we
agreed on how we want to handle them :-)
You've mentioned if being able to change the widget in the template it would
be cool to let the python source also know which widget should then be used to
parse the data. My concern about this was that an HTML data value should not
be allowed to exchange code parts on the server. Sure we would limit that to
specific widget classes, but with that power in HTML you would be able to
break the server side code, either by being evil or not understanding widgets
in total.
The same of course is true if we just change the widget without letting the
python form know what is happening, this makes it also possible to break the
server … we talked then about what a widget actually is: It has two purposes,
first is parsing the data making it usable for the field, second is
representational -- rendering an HTML input that is compatible with the
widget's data format.
So we decided to skip changing a widget totally in the form rendering.
Displaying a form and anything else that happens in the template has a
representational purpose, so we saw it would be out of scope for the project.
However changing the template that is used to render a widget will of course
still be possible (also passing in extra arguments etc.)
Now that we drop the idea of exchanging widgets we also don't longer need the
widgets template variable that holds the possible widget implementations you
can drop in. But the formfields var would be left to decide cases like:
{% formconfig widget using "textarea.html" for formfields.CharField %}
We decided to drop that variable as well, replacing it with a string that can
match the class name of a field:
{% formconfig widget using "textarea.html" for "CharField" %}
We justified it because this concept of matching a string to python structure
already exists. Examples are {% load mytemplatelib %} that loads a file named
after the argument, or some app.Model arguments used in third party libs.
There might be the concern that "CharField" is ambiguous if some else also
implements a "CharField". But this might be even a feature … if someone
implements also a CharField it might be very similar to django's built-in
one, otherwise you would name it differently.
btw I also plan to use "field" as argument for formconfig instead of "widget"
to match more the {% form[row|field] %} tags:
{% formconfig field using "textarea.html" with placeholder="type here
…" for "CharField" %}
Now to your django-forms implementation that has the "extends" argument for
the {% form %} tag. I still totally like the idea behind that, but like I
already said in the other message -- it might be confusing to have two
different meanings of the block tag. Carl has the same opinion here so we
won't include that into our implementation.
Thanks a lot again for your input, it created some vital think processes for
me and resulted in good improvements on the proposal (hope you see it the
same). Keep posting.
--
Servus,
Gregor Müllegger
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
