On Mon, Jul 12, 2010 at 8:16 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Mon, Jul 12, 2010 at 11:27 AM, Javier Guerra Giraldez
> <jav...@guerrag.com> wrote:
>> no, the P, UL (and my hypothetical left_table) would each one be a
>> class; you could import each one separately (or maybe several included
>> by default). in my example, left_table would inherit from as_table,
>> simplifying the implementation. the {%form%} syntax wouldn't be a
>> parameter to a single renderer, it's a selector to choose which
>> renderer to use.
>
> I'm not sure I understand.
>
> In my proposal, {% load custom_form %} loads a single form template
> tag. That template tag implements a single specific rendering scheme.
> You import library X, you get library X's layout. If you want a
> different layout, you import a different library (namespaces being one
> way to get around the 'multiple layouts in a single )
i didn't think too much about namespaces; maybe that's a cleaner
solution than my proposal.
> How are you getting your "as_p" renderer into your template? How is it
> made available to the {% form %} tag as an argument? How does the
> "selector" determine what is available for selection? What defines the
> default behavior of {% form %} in the first place?
what i think is: currently, the form system has a few renderers as
class methods. the new system would factorize them out as classes.
for this, it would expose a small API, so that the user could easily
write new renderers, ideally even supporting inheritance to make it
easier to just modify existing renderers.
a new renderer class would have to be registered with the form system,
just like a new template tag has to be registered with the template
system. this might be at app loading, or more likely, with {%load%}
tags on the template. you could {%load%} as many renderers you want,
since they don't overwrite any behavior, they don't define a new
{%form%} tag.
the {% form %} tag is provided by the form system, not by the
renderers. there are a few 'included' renderers, which probably you
don't have to load, (just like you don't have to load the standard
template tags). one of these would be the default (just like the
current form system has a default of as_table() )
a parameter to the {%form%} tag (or a subtag, on André's proposal)
would be the 'selector' to choose between the registered renderers.
again, the renderer doesn't override the {%form%} tag; it's the tag
the one that chooses the selected renderer.
--
Javier
--
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.
