Re: Form Rendering API Proposal
Hello, Le 25/06/2011 12:05, Bruno Renié a écrit : * If you want template-base widgets *now*, use django-floppyforms. * If you want to use the new forms / templates API as soon as it's done… how do you do it? Is it going to be packaged as an app, as a patched version of django? One option could be to use django-formrenderingtools and adapt it to the proposed API. Formrenderingtools does not cover exactly the proposed API yet, but I guess it could. In fact, formrenderingtools will be deprecated in next Django releases. So there is no interest in maintaining it "as is". Offering backward compatibility for the form rendering API may be the best way to go. The main repository is https://bitbucket.org/benoitbryon/django-formrenderingtools I just pushed it to github too (let's try hg-git) : https://github.com/benoitbryon/django-formrenderingtools Forks are welcome! This is only a suggest, so if most of you think we'd better fork another app or build a brand one... please let me know. I would stop committing on formrenderingtools and contribute to the other app instead ;) Benoit -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
Re: Form Rendering API Proposal
Le 23/06/2011 13:25, Idan Gazit a écrit :
http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
I'm still not convinced by the {% form myform hidden "honeypot" %} syntax.
Isn't it a duplicate of {% widget HiddenInput for form.honeypot %} and its {%
formconfig %} equivalent?
With a similar syntax we would write shortcuts like {% form not hidden "honeypot" %} or
{% form textarea "honeypot" %}... I guess those are bad ideas.
Benoit
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@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.
Re: Form Rendering API Proposal
Le 24/06/2011 01:02, Carl Meyer a écrit :
On 06/23/2011 04:43 PM, Jacob Kaplan-Moss wrote:
The wrong performance benchmarks could result in a veto from me; this
is important.
I really think templated form-rendering is a massive improvement in
Django for front-end devs, so I'm very hopeful that Armin's work can
make rendering speed a non-issue. No pressure, Armin ;-)
Carl
IMHO, templated form rendering is not an option, it already is a reality (and
performance already is an issue).
Templated form rendering is already a practice of several front-end devs:
* I believe many of us tried to include template snippets to be able to reuse
some form layouts (starting with {% include %})
* Since there is no de-facto convention for implementing the functionality
right now, everyone uses a personal recipe.
* There is no documentation about doing it right, with performances in mind.
* Maybe hundreds of front-end devs are doing it wrong because there is no
standard, with optimizations included.
I am currently using my own (shared) recipe for templated form rendering
(django-formrenderingtools) and I will keep using it until there is a standard
tool implementing such functionality.
For most websites I develop, I'd rather be able to develop them quickly with
nice reusable code than provide extreme performances.
For the websites which require high performances, I use the cache, and if it is
not enough, I can fallback to hard-coded form rendering.
So, in my case, hard-coded template form rendering is the option, whereas
templated form rendering is the standard.
Le 24/06/2011 06:42, Jjdelc a écrit :
Is it possible for a django user to overload {% formconfig %} to do
something else? or do we have to wait for a next Django release to
have new behavior?
I agree with Jjdelc: we should not be restricted to one hard-coded
implementation.
If someone has a solution to improve performance, or to match a project
specific needs, it should be possible to override the default.
Le 14/06/2011 11:38, Benoît Bryon a écrit :
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',
)
Configurable loaders are one way to be flexible.
Implementing the form rendering with class-based components is another.
We already have Python classes for widgets. There could be a widget class which
does not use templates and provide extreme performance.
Why not Python classes for other form elements? It would make it possible to
implement both hard-coded and templated solutions.
It is a great practice in django-floppyforms: use Python components with a
render() method. So let's apply this pattern to all form elements!
Could the "layout" parameter be, in fact, a reference to a Python class?
Something like this (to be consistent with the {% widget %} syntax)::
{% form AsTableLayout for form %}
{% form AsTableLayout %}
{% form %}
It should be possible to provide "generic" base classes which cover most of the
use cases.
And it would be possible to make hard-coded-high-performance layouts and
templated ones living together.
Benoit
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@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.
Re: Form Rendering API Proposal
Le 24/06/2011 06:42, Jjdelc a écrit :
{% formconfig widget "forms/widgets/textarea.html" for "comment" %}
or even
{% formconfig widget "comment" using "forms/widgets/textarea.html" %}
in order to mantain the same syntax for {% formconfig %}.
+1
A consistent syntax for all form components would be great.
Benoit
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@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.
Re: Form Rendering API Proposal
Le 23/06/2011 14:33, Jonas H. a écrit :
On 06/23/2011 02:11 PM, Harro wrote:
- Will the as_* methods on forms be deprecated? They seem to be a nice
shorter version then the new way to do it.
I'd rather provide a shorter version of {% form %} for built-in layouts:
{% form foobar 'table' %}
as shorthand for
{% form foobar 'forms/layouts/table.html' %}
Hi,
Legacy {{ form }} can be replaced by a short {% form %} if :
* the form tag looks for a context variable named "form" by default. This name
is used by some generic views. Isn't it a kind of convention?
* the default layout is the "as_table" equivalent.
--
Benoit
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@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.
Re: RFC: Templatetag API for form rendering
Hi,
Le 22/05/2011 22:21, Gregor Müllegger a écrit :
{% renderform my_form hidden "honeypot" %}
Render all fields but outputs the my_form.honeypot field as a hidden
field.
If one wants to force a field to be hidden, wouldn't it be better to use
a "hidden" widget?
Why provide a "hidden" argument when you could do it with a widget?
::
{% widget widgets.HiddenInput for "honeypot" %}
It would keep the renderform tag simple.
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 django-developers@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.
Re: RFC: Templatetag API for form rendering
I'm not sure yet, if it's worth the extra {% formdefaults %} tag. Ofcourse it
> prevents template authors from excidentally overriding defaults, but I think
> who will use these utilities must know about these implications anyway. It's
> somehow just reflecting the behaviour of a python module scope.
> But maybe I'm a bit too much programmer here and reflecting too much
> of my habits
> onto the template authors mind.
There are some key differences between this and Python module scope,
besides the usual "template authors aren't necessarily Python
programmers." The main one is that Python module scope is contained
within a single file; here we're talking about a global scope that
potentially extends across many template files, what with inheritance
and includes, and even into Python code files too. I think because of
this action-at-a-distance factor, there's a much greater need to make
the modification of global scope explicit, clear, and hard to do by
accident or overlook.
Maybe it could be useful to provide a test utility to make sure a layout can handle all
"standard cases".
I mean, if one wants to create a new layout and set it as the global default,
the layout should be tested. So a layout testing tool (or documented procedure)
would be great.
But I guess that is a bonus, not a required feature in the Gsoc.
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 django-developers@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.
Re: RFC: Templatetag API for form rendering - Second Edition
Le 03/06/2011 16:58, Gregor Müllegger a écrit :
{% formerrors %}
Will it use duck typing? rather than testing Form or Field or ErrorList or
ErrorDict subclasses.
Drawback:
more work needed since some refactoring of Form, BoundField, ErrorList and
ErrorDict may be required.
Advantage:
duck-typing (I mean kind of interfaces) would be more flexible: we will be
able to pass custom objects to {% formerrors %}.
Benoit
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@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.
Re: RFC: Templatetag API for form rendering
Le 22/05/2011 22:21, Gregor Müllegger a écrit :
{% renderform my_form %}
Another suggest from formrenderingtools...
Can we consider that "form" is the naming convention for form context variables?
* generic views use "form"
* there is usually only one form in a view
If "form" can be considered as a convention, could we apply "convention over
configuration" here?
::
{% renderform %}
Convention: use the "form" variable
Configuration: pass my_form as an argument
In formrendering tools, there are 2 kinds of context:
* form context: where a "form" variable is required in the context => form,
field list, form errors...
* field context: where a "form" variable is useful, and a "field" variable is
required => label, field errors, field, widget...
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 django-developers@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.
Re: RFC: Templatetag API for form rendering
Le 23/05/2011 00:21, Carl Meyer a écrit :
Just had a quick conversation with Gregor and Chris Beaven on IRC;
based on a comment of Chris', we discussed the possibility of ditching
the {% formlayout %} tag in favor of specifying the layout as an
argument to the {% form %} block tag. E.g. instead of
{% form %}
{% formlayout "table" %}
{% renderform my_form %} {# will use table layout #}
{% endform %}
You'd say:
{% form "table" %}
{% renderform my_form %}
{% endform %}
And perhaps if the layout can be specified that way, with minimal
boilerplate, we don't need the global-context-modifying version of
formlayout either.
From my experience, the most common use case would be to render one form using
one layout.
So passing the layout at the toplevel form tag would be nice.
However, what could be interesting with the {% formlayout %} modifier is that
you could use several layouts to render one form.
As an example:
::
{% form %}
{% formlayout "p" %}
{% renderform form.field1 form.field2 %}
{% formlayout "table" %}
{% renderform form.checkbox1 form.checkbox2 form.checkbox3 %}
{% endform %}
So I would say:
* add the layout as an argument of the toplevel {% form %} tag
* and keep {% formlayout %} as an option for specific use cases
I just realized that I adviced the opposite approach for hidden fields: not in
the {% form %} tag, but in modifier.
That is because I think that hiding fields is not the most common use case,
whereas using a specific layout is.
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 django-developers@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.
Re: RFC: Templatetag API for form rendering
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//.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.
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 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 %}
{% form using baz %}
{% form using foo bar %}
{% 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 django-developers@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.
Re: RFC: Templatetag API for form rendering - Second Edition
Le 03/06/2011 16:58, Gregor Müllegger a écrit :
Hi,
this is the second RFC regarding template form rendering API/syntax. The first
one defined how a complete form or a subset of fields will be rendered. I'm
now proposing more tags to render more details like only the label of a form
field.
Currently we haven't discussed how we will substitute what we currently do
with using::
{{ form.non_field_errors }}
{{ form.errors }}
{{ form.field.errors }}
{{ form.field.help_text }}
{{ form.field.label_tag }}
We will implement these with template tags that are aware of the currently
used layout:
Substituting {{ \*.errors }}::
{% formerrors %}
What about sharing primitives (templates) to display form errors and
messages from the message framework?
In a way, form errors are a kind of error messages, aren't they?
To go further, I am wondering if, in future, forms could generate other
types of messages, like warnings: they don't block the validation
process but the user may pay attention to them.
Maybe there could be a relationship between form validation and
generation of a messages.SUCCESS too.
Benoit
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@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.
Re: RFC: Templatetag API for form rendering
Hi, I am the author of the django-formrenderingtools package, which focuses on a template tag library to render forms. Currently widgets and formsets are not supported, but they could be. I guess it matches the subject of the GSoC. So I would be glad if you had a look at my work. It is certainly not perfect, but I did my best. Although the code is available since some time now (2009 as I remember) I really miss feedback from other users. I do not know if others are using the application, and if not, I do not know why. I recently worked on the following items so that you can review it quickly : * documentation * packaging * a demo project to discover the application and try it in a sandbox The version 0.2.1, released on last sunday, is tagged as "beta", but I am using it in production. I mainly miss feedback to be sure. I am open to any suggestions if I can help: * I can switch to Github if it helps * I can adapt the license * I will try to follow this GSoC and contribute to discussions I would be glad to share my work and contribute to this topic... Some links : http://pypi.python.org/pypi/django-formrenderingtools/ http://packages.python.org/django-formrenderingtools/ https://bitbucket.org/benoitbryon/django-formrenderingtools/src About the particular topic of your original post : http://packages.python.org/django-formrenderingtools/reference/template_tags.html http://packages.python.org/django-formrenderingtools/reference/template_names.html -- Benoît Bryon Makina Corpus -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
