Hi Chris, thanks Carl, 2011/7/9 Carl Meyer <[email protected]>: > Hi Chris, > > On 07/08/2011 04:00 PM, Chris Beaven wrote: >> ... >> 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).
Hm, hidden fields are something that I have not taken into account after our latest iteration. I think they are a bit special-cased and might need attention even if we drop changing-the-widget feature. I think it is also technically something different than just exchanging widgets since any form field is already aware about how it can be rendered with a hidden widget. That also solves the don't-break-my-python-from-the-template issue since we only use the hidden widget which is supported by the normal form field. See the "hidden_widget" attributes: https://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L45 > ... > >> 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" %}. Your example is already achieveable without introducing a new template: {% form form using %} {% formconfig field with required=0 %} {% include "forms/p.html" %} {% endform %} This of course only works since you don't want to change actual markup from "forms/p.html". Otherwise you must define a new template. And because the following examples are the same ... {% form myform using "forms/p.html" %} {% form myform using %}{% include "forms/p.html" %}{% endform %} ... is also my justification for having the second one ("using" inline) directly in the GSoC scope. "extends" is IMHO something very different, like Carl said, because it introduces a new idiom that is not already present in the current features of the template language. -- 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 [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.
