On Tuesday, July 12, 2011 4:17:08 AM UTC+12, Gregor Müllegger wrote:
>
> Hm, hidden fields are something that I have not taken into account after
> our
> latest iteration. I think they are a bit special-cased and might need
> attention even if we drop changing-the-widget feature.
>
Agreed, it'd
Hi Chris, thanks Carl,
2011/7/9 Carl Meyer :
> Hi Chris,
>
> On 07/08/2011 04:00 PM, Chris Beaven wrote:
>> ...
>> I guess this means that rendering a field as "hidden" in the template is
>> also out, since this needs to modify more than just the field's
>> representation (specifically, non_field_
Hi Chris,
On 07/09/2011 02:50 AM, Chris Beaven wrote:
> If we're going to keep things simple, why are we introducing the idea of
> inline "using" templates?
That's a good question. I wouldn't be gutted at all if we dropped
inline-using from the initial scope, too, because I really think
separate
Thanks for the followup reply, Carl.
Yes, I think I was a bit confused regarding "for". Sounds fine.
Your points about scope creep and keeping the proposal as achievable as
possible is also noted.
If we're going to keep things simple, why are we introducing the idea of
inline "using" templates?
Hi Chris,
On 07/08/2011 04:00 PM, Chris Beaven wrote:
> On Saturday, July 9, 2011 12:19:44 AM UTC+12, Gregor Müllegger wrote:
> [...] So we decided to skip changing a widget totally in the form
> rendering.
> Displaying a form and anything else that happens in the template has a
>
On Saturday, July 9, 2011 12:19:44 AM UTC+12, Gregor Müllegger wrote:
>
> [...] So we decided to skip changing a widget totally in the form
> rendering.
> Displaying a form and anything else that happens in the template has a
> representational purpose, so we saw it would be out of scope for the
Hi Chris,
2011/6/29 Chris Beaven :
>>
>> I think thats conceptually not possible. We simply can change the widget
>> during
>> template rendering time, which makes it impossible to decide in the python
>> code with which widget we end up. And theoretically we could even render
>> the
>> form twice
On Tuesday, June 28, 2011 11:56:41 PM UTC+12, Gregor Müllegger wrote:
>
> However I think these templatetags could go into a thirdparty app.
>
-0, changing a label / help text at least are pretty common cases - the
template designer shouldn't be at the mercy of the python form settings.
I'm glad
Hi Chris,
2011/6/27 Chris Beaven :
> How do I override a field's label or help text?
> Specifically, help text may need to look something like: [[Can this person
> manage {{
> site.name }}?]]
This isn't addressed with the proposed template tags. You can still write out
a single row by hand if you
Oh, and one more critical one:
How does the form in python have knowledge of the widget which the field was
rendered with as picked by the template?
This is critical since building the form's data requires using the widget's
value_from_datadict.
--
You received this message because you are sub
How do I override a field's label or help text?
Specifically, help text may need to look something like: [[Can this person
manage {{
site.name }}?]]
How are HTML classes specified for rows which are required / contain errors?
(and one more slightly obscure one, probably out of scope...)
How doe
Hi Benoit, hi Bruno,
2011/6/26 Benoît Bryon :
> 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
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
Hi all,
On Fri, Jun 24, 2011 at 12:38 PM, Gregor Müllegger wrote:
> Hi Jacob,
>
> 2011/6/23 Jacob Kaplan-Moss :
>> Hi Idan et al. --
>>
>> Thanks for putting this all together!
>>
>> In general, I like this a lot, and I'm always going to defer to the
>> eyes of someone like Idan who spends more t
I just want to quickly add a second mention for the importance of being able
to control row-level groupings of fields, as well as row-level attributes
such as classes. It's a problem I've run into many times and would love to
have included in the new form-rendering solution.
All the best,
Hi Jacob,
2011/6/23 Jacob Kaplan-Moss :
> Hi Idan et al. --
>
> Thanks for putting this all together!
>
> In general, I like this a lot, and I'm always going to defer to the
> eyes of someone like Idan who spends more time wrangling templates
> than I do. So I like the general gist, and I most don
Hi Preston,
2011/6/23 Preston Timmons :
> This looks excellent so far.
>
> Do {% formfield %} and {% formrow %} accept context like {% form %}
> does?
>
> Is there a way with {% formfield %} or {% formrow %} to set custom
> attributes like placeholder, autocorrect, etc.? I find this common
> requi
Hi Jonas,
2011/6/23 Jonas H. :
> 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' %
Hi Benoît,
2011/6/24 Benoît Bryon :
>
> 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.
I have also n
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 %
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
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 woul
1.Disk hits can be avoided using the django.template.loaders.cached.Loader.
We have a form rendering system that uses a lot of templates and it's being
used in some pretty big websites, so far I haven't notices performance
issues because of form rendering and we haven't use the cached loader as o
>
> {% formconfig widget widgets.Textarea for "comment" %}
> {% formconfig row using "forms/rows/ul.html" %}
>
> The first statement instructs the form to use a textarea widget for any
> formfield named "comment." The second instructs the form to use ul's as the
> default formrow template anytime a
On 06/23/2011 04:43 PM, Jacob Kaplan-Moss wrote:
> 1. Performance: it looks, to me, like rending a basic form is going to
> cause dozens of template includes and dozens of sub-renders (the form
> loads a form template which loads row templates which load widget
> templates). That's dozens of disk h
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 Idan et al. --
Thanks for putting this all together!
In general, I like this a lot, and I'm always going to defer to the
eyes of someone like Idan who spends more time wrangling templates
than I do. So I like the general gist, and I most don't mind the {%
formconfig %} business.
However, I do
I've been working on something almost identical to this. But your formconfig is
what really gives it that last piece that I didn't have, very nice!
I doubt that it's helpful, but I just put my code up at:
https://github.com/bunchesofdonald/django_amaro it's still very early stages,
and needs c
This looks excellent so far.
Do {% formfield %} and {% formrow %} accept context like {% form %}
does?
Is there a way with {% formfield %} or {% formrow %} to set custom
attributes like placeholder, autocorrect, etc.? I find this common
requirement when optimizing forms for mobile devices.
Thank
On Thu, Jun 23, 2011 at 10:11 AM, Idan Gazit wrote:
>
>
> On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote:
>>
>> What is the "significant wart" ?
>
> The formconfig tag is a little bit "magical"; there's no other example in
> the template langauge of something explicitly affecting stat
On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote:
>
> What is the "significant wart" ?
>
The formconfig tag is a little bit "magical"; there's no other example in
the template langauge of something explicitly affecting state in the same
fashion. Even things like the "with" tag are s
On Thu, Jun 23, 2011 at 8:25 AM, Idan Gazit wrote:
> At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about
> his work on a revised form rendering API:
> http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
> I sat dow
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/layou
Hi Harro,
2011/6/23 Harro :
> Two things:
> - Will the as_* methods on forms be deprecated? They seem to be a nice
> shorter version then the new way to do it.
The plan is to deprecate them. First reason is that the new approach
is more explicit of what happens. The second and main reason is, tha
Two things:
- Will the as_* methods on forms be deprecated? They seem to be a nice
shorter version then the new way to do it.
- I assume the formconfig calls are for the current context, but can I set
them in the base.html and then automatically have them used in all templates
extending the ba
35 matches
Mail list logo
