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
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
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 "l
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
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
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"
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
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:
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
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
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
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.
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
13 matches
Mail list logo
