On Tue, Jul 13, 2010 at 3:24 AM, Carl Meyer <carl.j.me...@gmail.com> wrote:
> Hi Russ,
>
> First of all, thanks very much for this proposal! Form rendering has
> been a major pain point for us (thus the existence of
> django-form-utils), and improving it is tops on my 1.3 wishlist. I
> will also be at DjangoCon and eager to sprint in this area.
Excellent. Sounds like we might have a posse of form wranglers forming.
> I'll first outline in brief what I think a fully template-oriented
> approach might look like, address some possible concerns with it, and
> follow that with some specific comments on your proposal.
>
> A fully template-based approach to form rendering
> =================================================
An interesting counterproposal Carl; thanks for the input.
> Possible objections
> -------------------
>
> - Russ mentions the "complexity" of "getting all the template paths
> lined up." I'm not sure what the issue is here; Django template
> overrides use a simple path-based scheme, and it's a proven system
> that works. Designers use it successfully all the time. I think
> introducing new complexity in the form of new Python abstractions is
> more likely to be a real problem.
To explain my concerns, I perhaps need to explain my motivation better.
When I introduced the Media framework 3 years ago, I had something
very specific in mind: I wanted to start a marketplace for reusable
widgets.
I have exactly 0 mad skillz as a front end guy, but I know that rich,
pretty ajax widgets et al are necessary for a good user experience. My
goal, as a backend guy with limited frontend skills, was to find a way
to get the people who *did* have frontend skills to be able to package
their widgets in such a way that I could reuse them.
Before the design community starts to think that I'm trying to
minimize the importance of what they do -- I know that there's a lot
more to the design process than this. I'm just looking at this from a
prototyping perspective -- I should be able to get a decent calendar
or AJAX autocomplete onto a page without much more effort than it
takes to put a simple text field on the page. The legacy of "How does
Django do AJAX" questions on django-users is the more public face of
this desire.
Now, the Media framework has been largely a flop in this regard
(although we may be able to use bits of it in a support role in this
new form work). However, my desire for a widget library is unquenched
:-)
My concern about doing this entirely in templates is that it makes the
process of sharing a widget library a little more difficult. If it's
just code, then it just needs to be in the PYTHONPATH. If there are
templates too, then the templates need to be somewhere that they can
be accessed.
There's also more to a widget in this context than just the template
-- for example, there's nominating the javascript triggers that the
widget requires.
I'm not saying that these problems can't be overcome -- just that it's
a complexity that I want to make sure is covered.
> - Concerns about filter syntax. The first two concerns Russ raised are
> only issues if many filters have to be strung together, which this
> proposal does not require. The third objection is predicated on the
> necessity of doing tricks with the context to load widget JS; again,
> a template-based solution doesn't need this.
The filter syntax doesn't hit the 'render the form completely standard
except for this one change on this one field' use case. However,
there's nothing about the 'template' aspects of your proposal that
need to be bound to filters; they could be equally accomodated in a
template tag.
> - "Too much work to override all these widget templates just to switch
> doctypes!" Again, I think the complexity of dedicated Python
> machinery is likely to be worse. Django's philosophy (and James
> Bennett's philosophy of reusable app templates, referenced above)
> assume that templates should be per-project: why should forms or
> widgets be different? Packaging up a reusable app with a set of
> generic "HTML5" or "XHTML1" widget templates is almost certainly
> simpler (and less bug prone) than writing the equivalent Python code
> for the customized {% form %} tag renderer.
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...
> - I'm skeptical that the "chrome" abstraction buys very much in
> exchange for the overhead of the new concept and the syntactical and
> registration problems. As mentioned above, in practice I don't think
> layering different chromes on top of each other will work very
> often; they'll frequently have to be manually integrated into a new
> unified chrome anyway.
This depends a little on the level at which chrome is implemented.
Very low level "modify attribute" and "add class" chrome could easily
be layered, and would address the common request of "how do I add
class X to my widget". More complex chrome (like the skeleton for a
calendar widget) would require more markup, and probably wouldn't be
mixed with other complex chromes, but it might still be mixed with a
simple chrome to add a class or an attribute (or a collection of
attributes and classes packaged into a single chrome).
> I'm also concerned that it's still insufficiently flexible; the core
> input tag markup will still be hardcoded in the widget, thus
> requiring special-cases for anything in it that you might want to
> tweak (doctype, extra classes or attributes). This is the big one
> for me, as it means our core problem with the current system (markup
> hardcoded in Python code) would not be fully fixed.
>
> In contrast, being able to directly edit widget templates for your
> specific cases is simpler, more intuitive for designers, and fully
> flexible.
Classes and attributes on the base widget are something that could be
modified with chrome. If you look at the API for widget.render() right
now, it's pretty flexible -- the issue is that there's no programatic
way to get at that API from a template. Chrome is the way into that
existing API, as well as providing a way to wrap decorating HTML and
Javascript around the base widget.
What exactly is your use case for something that designers want to
customize in the raw widget that widget.render() doesn't expose?
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.
