Hi Chris,
On 07/08/2011 04:00 PM, Chris Beaven wrote:
> 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).
We can always revisit additional features later if needed, but scope
creep is a GSoC-killer.
I think most of the use cases for replacing widgets in the template are
really purely representational, they don't change the server-side data
handling at all. In cases where it would, the existing proposal was
already inadequate. And the majority of cases, when it wouldn't, can be
handled just by swapping in a different template; there's no need to
care about the widget class. If the form officially is using a TextInput
widget on the Python side and you swap in a template for that field that
renders a select dropdown, the Python code won't care; it still gets a
name and a value in request.POST.
> 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).
Yes. I mean, you're fully free to render a field as hidden yourself (via
template), but anytime you make a change in the HTML that implies any
change in server-side data handling, you're on your own to figure out
the right solution for your case (which is no different than now).
> 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.
Seems like there might be a small misunderstanding here. The shown
syntax is for overriding the widget template used for any instances of a
given _field_ type, not a given _widget_ type. I agree that a more
common use case is probably changing things up for a particular field in
your form, but having this allows the possibility of reusable form
layouts that can do interesting things with representations of
particular field types.
> 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.
I think it's actually pretty intuitive in practice that the operand of
"for" can be either the name of a specific field, or the name of a field
class. Ambiguity isn't an issue; specific field names take precedence
(and capitalization conventions should prevent ambiguity anyway). And
like I said above, I think the latter is useful for reusable form layouts.
> 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.
Why would you otherwise have to redefine the whole form template? A form
template is a normal template; you can put blocks in it and have another
form template extend it and override those blocks. I don't think it's
onerous (in fact, I think it's clearer and more maintainable) to do this
in a separate file rather than "inline" as your proposal does. And I'm
strongly in favor of reusing existing template language features and
conventions rather than inventing new and confusing syntax for "inline
extends"; IMO redefining the meaning of {% block %} contextually is
simply a non-starter due to the extra difficulty in quickly
comprehending template structure.
AFAICT, your proposal doesn't actually bring any new capabilities to the
table, it just lets you do the same thing inline rather than in a
separate form template file that you reference with "using".
> 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 would just create a template "forms/p-no-stars.html" (or whatever)
that {% extends "forms/p.html" %} and overrides the config block in the
same way, and then you'd just say {% form form using
"forms/p-no-stars.html" %}.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
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.
