On Wed, Jul 14, 2010 at 8:42 AM, Tai Lee <real.hu...@mrmachine.net> wrote:
> Hi Russ and Carl,
>
> On Jul 14, 5:55 am, Carl Meyer <carl.j.me...@gmail.com> wrote:
>> Hi Russ,
>>
>> On Jul 13, 12:11 pm, Russell Keith-Magee <russ...@keith-magee.com>
>> wrote:
>>
>> > My manifestation of this problem is slightly different -- it's the
>> > issue of how to ship a widget library that can be used anywhere. I
>> > suppose one argument here is that you just need to advertise your
>> > chrome with doctype support notes.
>>
>> > Alternatively, since this is a template language, you could always
>> > introduce an {% if %} block and render conditionally on doctype...
>>
>> Exactly. I can imagine a number of different ways a reusable widget
>> library might approach this problem: simply advertise support for a
>> certain doctype (don't discount the value of supporting this low-
>> barrier-to-entry option, even if it isn't ideally reusable), or use
>> template conditionals, or provide separate widget templates for
>> separate doctypes... I find it preferable to make the full power of
>> the template language available, and then let template authors use the
>> tools they know to iterate towards best practices in this area, rather
>> than hardcoding into Django particular ideas of which doctypes are
>> relevant and what changes have to be made in templates to support
>> them. It's not just a matter of closing slashes, also which attributes
>> are valid (of which there may be more added later that we don't even
>> know about now)... I think hardcoding current assumptions about
>> doctypes is just asking for maintenance headaches. I'd much rather
>> leave that concern where it belongs, fully in the hands of template
>> authors.
>
> I wouldn't like to see widget libraries being packaged up with
> templates including conditional templates based on doctype. This seems
> messy, not friendly to override in your own templates, and effectively
> combining what should be multiple separate templates into one.
>
> Wouldn't a mechanism that allows the path from which templates are
> loaded to be changed benefit both widget libarary authors and the
> designers who are implementing those widget libraries? A widget
> library author would include and advertise templates for each doctype
> they support, e.g. "html4/mywidgetlibrary/forms/datetime.html" and
> "xhtml1/mywidgetlibrary/forms/datetime.html", then the designer would
> use:
>
> {% templatedirs "html4/mywidgetlibrary" %}
> {{ myform }}
> {% endtemplatedirs %}
>
> or:
>
> <form ...>
> {{ form.myregulartextfield %}
> ...
> {% templatedirs "html4/mywidgetlibrary" %}
> {{ myform.mydatetimefield }}
> {% endtemplatedirs %}
> </form>
I'm not wildly enthusiastic about this. You've posted this snippet (or
something like it) a couple of times, and every time my immediate
reaction has been "You're in a twisty maze of endtemplatedir tags, all
alike" :-)
I can see what you're trying to do in terms of setting default
directories; but the syntax you are proposing:
* makes the representation of setting a default over a wide range quite elegant
* makes the representation for overriding a default on a single
field/form quite verbose.
To me, this seems like priorities the wrong way around. Overriding a
single default should be the simple case, not the verbose case.
Consider the template where you want to override the default widget on
every field on a form - your entire form will potentially be a nest of
{% templatedir %}{% endtemplatedir %} tags.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
