On Saturday, July 9, 2011 12:19:44 AM UTC+12, Gregor Müllegger wrote:
>
> [...] 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.)
>
Fair enough, I understand the concern with giving HTML power over choice of
rendered widget (not sure I totally agree, but concede that it's easier to
not have to worry about it).
I guess this means that rendering a field as "hidden" in the template is
also out, since this needs to modify more than just the field's
representation (specifically, non_field_errors).
> 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 %}
>
[or]
>
{% formconfig widget using "textarea.html" for "CharField" %}
>
I'm not sure I see the importance of overriding a widget's template, to be
honest. IMO it seems much more likely that you'll be worried with alternate
rendering for different fields rather than all widgets.
> 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.
>
That's a bit of a far-reaching justification, but I'm indifferent about the
whole widget template bit of the proposal, so roll with whatever makes most
sense.
> 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" %}
>
I worry that we're introducing two meanings of what 'for' represents. Again,
it seems to make more sense in my mind that it'd be in context of a field,
not a widget.
> 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.
>
(Note that 'extends' also applies the formconfig, row and field tags too)
I understand the potential for confusion, but I think it really does bring
something big to the table which is unfortunate to miss out on.
For example, if I just want to customize one field template on a form then
without this I have to redefine the whole form template.
It also allows for complex redefinition of a field's label and help text
without having to redefine the entire field template.
We're already bringing a new concept of inline sub-template definition via
the 'using' argument.
I don't see that it's much more of a push to simultaneously introduce inline
sub-template extension via the 'extends' argument.
Here's real-life example off the top of my head we had the other day. A
client had a multi-step registration form. Usually, our rows show a * next
to the label of required fields but all of the first step was required so
the client didn't want the stars to show. I envision this would look like
this in django-forms (lets assume we've customised 'forms/field/base.html'
to conditionally conditionally change the label class or just conditionally
add the * after it):
{% form form extends "forms/p.html" %}
{% block config %}
{% formconfig field with required=0 %}
{% endblock %}
{% endform %}
What would this look like with the current form proposal?
>
--
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/-/rkqDXMP8x6AJ.
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.
