Le 24/05/2011 16:35, Gregor Müllegger a écrit :
This is not yet defined in detail. I would suggest a schema like:
forms/layouts/<layout name>/<template name>.html
Resulting in templates for the layout "table" like:
forms/layouts/table/row.html
forms/layouts/table/label.html
forms/layouts/table/field.html
forms/layouts/table/errors.html
forms/layouts/table/help_text.html
In django-formrenderingtools, I first tried a schema similar to the one you are
suggesting.
But I eventually chose a different schema:
forms/layouts/{{ LAYOUT_NAME }}/{{ ELEMENT_NAME }}/{{ TEMPLATE_NAME }}
where :
* {{ LAYOUT_NAME }} is "table" in your examples,
* {{ ELEMENT_NAME }} stands for row, label, field, errors...
* {{ TEMPLATE_NAME }} is "default.html by default, but can be overriden by passing a
"template" argument to the template tag.
I chose this schema because it allows layout variations and thus limits the
need to create new layouts.
What if one wants a specific layout for one field in one form?
* with your schema, he creates a new layout (involving several templates?).
* with the formrenderingtools schema, he overrides the layout (involving one
template).
If there can be plenty of templates for several fields or forms in a layout, the layout
directory could become a mess. Which ones are templates for fields? Which ones are
templates for labels? We could use a filename prefix like "field_", but a
folder may be more pertinent.
In addition, in formrenderingtools, field's name is used to search for a
template like firstname.html before default.html.
If the template is well-named (i.e. {{ field.html_name }}.html), then there is
no need to specify the new template.
I find it really useful, but it can lead to namespace errors (what if a field is named
"default"?). So maybe it is not a so great idea.
For details about the template names in formrenderingtools:
http://packages.python.org/django-formrenderingtools/reference/template_names.html
(it misses the "field.html_name" tip)
Layouts have to be easy to use, but also easy to create.
For the creation purpose, think about layout inheritance.
As a template designer, I do not want to rewrite or copy all the base layout
when I just want to customize a few items.
As an example, Django's default behavior is to display a ":" beside the<label>.
If I want to remove or replace it, I do not want to create a brand new layout with
all templates! I just want to override the<label> item.
Note: for french, we'd better use a " :". I mean the ":" element is not standard, so
I don't like it and I used to remove it or sometimes use some {% trans ":" %}.
There are at least 2 ways for inheritance.
1. inheritance using {% block %} tags.
Roald de Vries showed some ways to use it in his mail on 10/06/2011.
Right now, I not convinced it is a good idea. From my point of view, the syntax
is not light enough to write.
2. template fallback mecanism.
It is somehow implemented in formrenderingtools. For a given layout, you use
select_template() to get a specific template and fallback to the default if
necessary.
Formrenderingtools allows only 2 levels for field list elements: specific and default. As
a consequence, you cannot override a layout which is not the default one. If
"as_ul" layout is not the default, you cannot override just a part of it. You
have to copy all the templates in a new layout and then modify a part. That is bad.
But what if we could say: "use foo layout, or fallback to, in order, bar, baz or
default"?
A suggest about the n°2 implementation:
::
{% renderform %}<!-- uses default layout -->
{% form using baz %}<!-- uses baz layout or fallback to default -->
{% form using foo bar %}<!-- pushes bar then foo to the stack of layouts -->
{% endform %}
{% endform %}
Another idea: what if we got "layout loaders"?
FORM_LAYOUT_LOADERS = (
'my.custom.app.SelectLayoutMatchingUserPreferences',
'another.custom.app.SelectLayoutMatchingUrl',
'another.custom.app.SelectTemplateMatchingFieldHtmlName',
'django.forms.layouts.loaders.FallbackLayoutLoader',
)
Benoît
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
