/* I posted this message few days ago - but it is not here so I try it
again. I am sorry for possible double post. */

> Here's my first cut at a list of the use cases we need to support:
>
> We need to be able to define templates for:
>
>  a) The layout for a single widget (e.g., a DateWidget)
>  b) The layout for a single row of a form
>  c) The layout for an entire form (top errors, fields, hidden fields)
> in as_* style.
>
> In each of these templates, (b) will need to render instances of (a),
> and (c) will need to render multiple instances of (b) -- and not
> necessarily the same instances, either.
>
> Each of templates could be applied:
>
>  1) As a background system default - what you get if you don't override 
> anything
>  2) As a specified default for the entire rendered page
>  3) As a specified default for a single form on a page
>  4) As a specified override for a field on a form (a/b) or a form as a whole 
> (c)
>
> There's also the issue of doctypes; If I have a document that is html4
> document, I need to ensure I only get html4 snippets; ideally without
> having to specify html4 every time I use a snippet.
>
> If anybody has any other use cases or points worth considering, please speak 
> up.

Hi,

I use templates for rendering of my forms (with exception of widgets -
but I would prefer to use templates also for them) so I like template-
based proposal. And I have some more notes based on my experiences:
1. Rendering of some parts of forms depends on current context -
fields are different in simple forms and in forms which are parts of
formsets. But widgets are generally same in each context.
2. There are more variants how to customize only parts of forms - you
can customize all widgets of given type in the form or only one
field.
3. It is quite difficult to create templates which are easy and
customizable at once - my templates work but I have problems to
comprehend them.

I would like to propose following approach:
1. There are not only two form renderers as in Carl's proposal
(render_form and render_field) - each component (formset, form,
fieldset, field, widget and errors) has its own renderer. (I do not
say if it could be filter or tag or if it could be one filter/tag for
each component or one generic one which would only called something as
render method of the component - it would be next step to decide it.)
2. Each renderer would only call render_to_string with list of
template names (defined in the following paragraph) and with the
component in template context.

List of templates would be created from the following items (it is not
so difficult as the description):
1. Settings FORMS_TEMPLATE_PREFIX - "django/forms" by default.
2. Formset's name - could be defined in python code or by template
author, for example "permission_list".
3. Form's name - could be defined in python code or by template
author, for example "contact_form".
4. Fieldset's name - could be defined in definition of the fieldset,
for example "personal_info".
5. Field's name - defined in definition of the field, for example
"username".
6. List of form styles - could be defined by templates' authors (step
by step), for example "table_form", "html, table_formset" or "xhtml,
div_form".
7. List of templates for each component - defined in the component's
class, for example "date_field.html, field.html" for DateField or
"email_widget.html, widget.html" for EmailWidget.

For example, EmailField "sender" in form with name "contact_form" in
form style "table_form" would use following list (in reality only one
template or a few templates would be defined):
- django/forms/contact_form/sender/table_form/email_field.html"
- django/forms/contact_form/sender/table_form/field.html"
- django/forms/contact_form/sender/email_field.html"
- django/forms/contact_form/sender/field.html"
- django/forms/contact_form/table_form/email_field.html"
- django/forms/contact_form/table_form/field.html"
- django/forms/contact_form/email_field.html"
- django/forms/contact_form/field.html"
- django/forms/sender/table_form/email_field.html"
- django/forms/sender/table_form/field.html"
- django/forms/sender/email_field.html"
- django/forms/sender/field.html"
- django/forms/table_form/email_field.html"
- django/forms/table_form/field.html"
- django/forms/email_field.html"
- django/forms/field.html"

Some use cases:
1. I want to use templates from Django, but with html: Use "html" form
style in your template.
2. I want to use custom date widget's renderer for all my forms:
Define template "django/forms/date_widget.html".
3. I want to use custom field's renderer for all my fields with
"table_form" style: Define template "django/forms/table_form/
field.html".
4. I want to use custom email widget's renderer for "contact_form":
Define template "django/forms/contact_form/email_widget.html".
5. I want to use custom field errors' renderer for "username" field in
"contact_form": Define template "django/forms/contact_form/username/
errors.html".
5. I want to use different email widgets' renderer for admin: Define
"django/forms/admin/email_widget.html".
6. I want to implement reusable widget "MyGreatWidget" defined in
xhtml variant be default, but with support for html: Define template
"django/forms/my_great_widget.html" and "django/forms/html/
my_great_widget.html".

-- 
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.

Reply via email to