On Mon, Jul 12, 2010 at 2:14 AM, 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.
I'm in completely agreement on this. One of the reasons I posted this in an incomplete form is to get feedback. Feedback from the designer community on the utility of the interface is a big part of this, both in terms of how the tag would be used, and how new tag implementations would be defined. I'm not 100% convinced that templates are the answer, but they're certainly worth considering. I have two immediate concerns: - the complexity of getting the templates picked up by the form rendering template tag (getting all the template paths lined up so that they are discovered and used correctly) - the performance overhead of using templates to handle very small template snippets. This is less of a concern now that we have cached loaders, but One possibility might be to include a template-based implementation of form rendering as one of the default implementations. This way, the template-based tag would be a gateway drug that designers could use to prototype a new style; if a particular rendering needs to be optimized or becomes common across multiple projects, it should be easy for a developer to take a bunch of prototype templates and turn them into a native implementation. 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.
