Hi, thanks for the proposal!
One thing that might be worth looking at is templatetag namespaces.
There are a couple of issues that I see emerging with this changes.
It's been mentioned before that one would like to render with different {%
form %} tags different forms in one template, namespaces would allow this.
Imagine now, that with this proposal addition some chrome libraries start to
appear. What about using chromes from more than one library? Or combining
chromes? I imagine that each library would start namespacing the chromes in
their names, so that their names don't clash. This isn't a nice solution.
There's been some work in this before:
http://code.djangoproject.com/ticket/2539
What do you think?
Iván
On Sun, Jul 11, 2010 at 3:14 PM, flo...@gmail.com <flo...@gmail.com> wrote:
> I'm glad to see that some serious thought is going into this issue!
> This proposal sound very good (to me, at least) on the whole.
>
> One thing that occurs to me, though, is that the people who are going
> to want to customize form output are very frequently going to be the
> people working mostly in the templates: the designers. It looks like
> you're not fully settled on the interface, but I think that exposing
> it on the form class like as_* means that it's going to be difficult
> for designers to customize that output.
>
> It seems to me that one way to give designers the ability to customize
> that output is to move some of that output logic out of Python and
> into templates. Widgets could load up a template from a well-known
> location--something like e.g. django/widgets/textarea.html--and then
> template authors could customize that by providing their own template
> in that same path. There would be some issues to sort out there, like
> the fact that Django would have to install some implicit Django-
> provided template directory at the end of TEMPLATE_DIRS, but I don't
> think that's too onerous.
>
> I'm not 100% sure that that's the answer, but whatever the answer is,
> I think it's important to note that the target audience for
> customizing form output isn't always going to be the Python
> programmer.
>
> Thanks,
> Eric Florenzano
>
> --
> 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<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
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.
