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" a
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:
duck
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
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 o
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.h
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.
Curr
Hi Gregor,
On the way home from DjangoCon I realized there is a (IMHO) elegant
solution to this problem that is closer to the nature of django's
template language.
What you want with form-rendering is having defaults, but being able
to override them; which is something you can do with dja
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
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 certain
On 05/24/2011 09:35 AM, Gregor Müllegger wrote:
>> Which templates are involved in a form layout?
>
> 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
>
Hi Gregor,
On 05/24/2011 09:25 AM, Gregor Müllegger wrote:
>
> Yes, defining a global default is really useful, we shouldn't skip that.
Yep, I'm definitely converted to that position ;-)
>> For the case-by-case override, though, I'd still much rather write
>>
>> {% form "table" %}
>> {% renderf
Hi Preston,
2011/5/23 Preston Timmons :
> This looks interesting so far.
>
> How does setting the form layout affect rendering individual fields in
> a form?
>
> Is the output of {% renderform my_form "first_name" %} equivalent to
> {{ form.first_name }}, or is it more like the output of "as_p" or
2011/5/23 Carl Meyer :
> I guess I was comparing
>
> {% form %}
> {% renderform myform %}
> {% endform %}
>
> to
>
> {% form "table %}
> {% renderform myform %}
> {% endform %}
>
> and thinking the latter didn't seem too comparatively onerous, even if
> you were doing it for every form render. Bu
This looks interesting so far.
How does setting the form layout affect rendering individual fields in
a form?
Is the output of {% renderform my_form "first_name" %} equivalent to
{{ form.first_name }}, or is it more like the output of "as_p" or
"as_table"? Which templates are involved in a form l
Hi,
I like the API and I'm looking forward to this. Just a small comment
on the {% widget %} tag:
On Sun, May 22, 2011 at 10:21 PM, Gregor Müllegger wrote:
> (You can read this RFC online if you prefer:
> https://github.com/gregmuellegger/gsoc2011-stuff/blob/master/rfc_syntax.rst )
> {% widg
Hi Jonathan,
On 05/23/2011 04:30 AM, Jonathan Slenders wrote:
> 1. Like Carl said, I always prefer template tags which alter the
> context to create a scope. (I hate {% url ... as varname %})
>
> {% form "table" %}
> {% renderform my_form %}
> {% endform %}
Well, in any case, not all context
1. Like Carl said, I always prefer template tags which alter the
context to create a scope. (I hate {% url ... as varname %})
{% form "table" %}
{% renderform my_form %}
{% endform %}
2. Also totally agreed with Russell that we need consistency about
when template tag parameters need to be q
On 05/22/2011 08:54 PM, Russell Keith-Magee wrote:
> My argument: I'm trying to think of another example in Django's
> template language where the template tag is an "action" in this way.
> To my reading, outside of the tags used for logic (for, if, etc), and
> tags that define a contextual block (
On Mon, May 23, 2011 at 9:00 AM, Carl Meyer wrote:
>
>
> On 05/22/2011 07:22 PM, Russell Keith-Magee wrote:
>> On Mon, May 23, 2011 at 6:21 AM, Carl Meyer wrote:
>>> Just had a quick conversation with Gregor and Chris Beaven on IRC;
>>> based on a comment of Chris', we discussed the possibility o
On Mon, May 23, 2011 at 8:44 AM, Carl Meyer wrote:
>
>
> On 05/22/2011 07:18 PM, Russell Keith-Magee wrote:
>> I like this. Simple, covers all the common use cases that I can see.
>> My only feedback here would be mostly bikeshedding -- the fact that {%
>> form %} is a configuration action, and {%
On 05/22/2011 07:22 PM, Russell Keith-Magee wrote:
> On Mon, May 23, 2011 at 6:21 AM, Carl Meyer wrote:
>> 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 specifyi
On 05/22/2011 07:18 PM, Russell Keith-Magee wrote:
> I like this. Simple, covers all the common use cases that I can see.
> My only feedback here would be mostly bikeshedding -- the fact that {%
> form %} is a configuration action, and {% renderform %} is the
> rendering action. It feels to me li
On Mon, May 23, 2011 at 6:21 AM, Carl Meyer wrote:
> 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
On Mon, May 23, 2011 at 4:21 AM, Gregor Müllegger wrote:
> (You can read this RFC online if you prefer:
> https://github.com/gregmuellegger/gsoc2011-stuff/blob/master/rfc_syntax.rst )
>
>
> Hi,
>
> like you might know I've prepared as pre-work to my GSoC project a repository
> [1] with examples fo
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
(You can read this RFC online if you prefer:
https://github.com/gregmuellegger/gsoc2011-stuff/blob/master/rfc_syntax.rst )
Hi,
like you might know I've prepared as pre-work to my GSoC project a repository
[1] with examples for two different approaches to my upcoming work on the form
rendering. T
27 matches
Mail list logo