I suggest reading this proposal online: https://gist.github.com/898375
It's exactly the same as below but formated nicely.
GSoC 2011 Proposal - Revised form rendering
Hi my name is Gregor Müllegger. I'm a Computer Science student in Germ
Hi Carl and Gregor,
On 2 апр, 01:17, Carl Meyer wrote:
>
> > 3. The designers I worked with are often interested on adding custom css
> > class
> > or an attribute to a form field. Most of the time this is really a pain
> > to
> > do if you don't have control over the python form code. Im
Hi Mikhail,
On 04/01/2011 05:09 PM, Mikhail Korobov wrote:
> Hi Carl and Gregor,
>
> On 2 апр, 01:17, Carl Meyer wrote:
>>
>>> 3. The designers I worked with are often interested on adding custom css
>>> class
>>>or an attribute to a form field. Most of the time this is really a pain
>>> t
On Sat, Apr 2, 2011 at 5:20 AM, Carl Meyer wrote:
>
> On 04/01/2011 05:09 PM, Mikhail Korobov wrote:
>> Implementation:
>> https://bitbucket.org/kmike/django-widget-tweaks/src/0e9bac3c71bd/widget_tweaks/templatetags/widget_tweaks.py
>
> That's quite a neat app - I have some similar template filte
2011/4/2 Russell Keith-Magee :
> I think this would be a good way to structure the project -- i.e.,
> keep a clear conceptual separation between hooks and configuration
> options that need to be added to Django in order to make an external
> form rendering library possible, and the library that act
Hi django developers,
GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form
rendering) seems to get stuck because of performance issues.
Question 1. Am I understand this correctly and the limiting factor is the
template rendering speed?
Question 2. Is it true tha
Hi all,
I'd like to propose a few extensions to Django's form library for 1.3.
I'm still working on some fine details, but before I get too far, I'd
like to field opinions so that I can:
* Discover any edge cases I've missed in my analysis
* Field any criticisms from people with more design/fro
On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase
wrote:
> [please excuse the slight chop-up-and-reordering of your
> original into my quoting]
Only if you grant me the same liberty :-)
> On 07/11/2010 10:36 AM, Russell Keith-Magee wrote:
>> {% form myform field birthdate using calendar important %}
>
04/01/2011 11:57 AM, Gregor Müllegger wrote:
> I suggest reading this proposal online: https://gist.github.com/898375
> It's exactly the same as below but formated nicely.
>
>
> GSoC 2011 Proposal - Revised form rendering
>
>
&g
Müllegger wrote:
>> I suggest reading this proposal online: https://gist.github.com/898375
>> It's exactly the same as below but formated nicely.
>>
>>
>> GSoC 2011 Proposal - Revised form rendering
>>
>>
>>
On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger wrote:
> I suggest reading this proposal online: https://gist.github.com/898375
> It's exactly the same as below but formated nicely.
>
>
> GSoC 2011 Proposal - Revised form rendering
>
On Sat, Apr 2, 2011 at 10:45 PM, Russell Keith-Magee
wrote:
> Secondly, it may be possible to play a trick on the template compiler.
> Jonas Obrist suggested this trick to me at Djangocon (US) last year;
> however, I haven't had a chance to dig into it any more.
>
> The trick goes something like t
Hi Yuri,
thanks for your toughts.
2011/4/2 burc...@gmail.com :
> Gregor,
>
> Regarding proposal itself,
>
> the idea to make django form rendering based on templates is good, but
> I think it should be simple, modular and not much verbose.
> I'd like more to see more modular, but easier syntax:
>
Hi,
2011/4/2 Russell Keith-Magee :
> On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger
> wrote:
>> I suggest reading this proposal online: https://gist.github.com/898375
>> It's exactly the same as below but formated nicely.
>>
>>
>> GS
Haven't got time for a full review of this proposal right now, but I've done
a lot of thinking about this area already and am more than happy for anyone
to steal my ideas and compare thoughts.
Shoot me an email off-list or catch me on #django (as SmileyChris) if you
want to discuss more persona
First off, for some arcane reason Google is forcing formatting on me.
Hopefully that doesn't make this email that ugly.
Anyway, as the current lead on Django Uni-Form I think its great that Gregor
is picking up the torch for refactoring form rendering in Django 1.40. He's
obviously done his ho
al. Mainly the media tag part and the timeline estimates
(nothing really exciting for the moment). A revision of the chrome section
will follow tomorrow. Have a look at the proposal online [1] or look below,
I've included the changed bits:
GSoC 2011 Proposal - Revised form rendering
=
On Sun, Apr 3, 2011 at 11:46 PM, Gregor Müllegger wrote:
> Hi,
>
> 2011/4/2 Russell Keith-Magee :
>> On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger
>> wrote:
>> Firstly, while it looks fine for a small example, I can see how it
>> would rapidly deteriorate if you have lots of fields, or lots
Sorry for the quite late response, everything is getting pretty close to the
deadline. I'm not happy with it but I need to tackle some personal issues at
once.
2011/4/5 Russell Keith-Magee :
>
> ...
>
> In particular, I have two objections:
> * it feels like it's trying to cram too much into a si
I finally submitted my proposal to the google melange homepage. The core of
the proposal is very much unchanged to the first draft, however I've included
passages that indicate that the syntax might change in further discussions
about this topic and that the concept of a chrome will be propably dro
Hi Mikhail,
On 03/29/2012 01:31 PM, Mikhail Korobov wrote:
> GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form
> rendering) seems to get stuck because of performance issues.
>
> Question 1. Am I understand this correctly and the limiting factor is
>
Hi,
Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
> I'd like to propose a few extensions to Django's form library for 1.3.
First of all, thanks or your proposal, the current form rendering is the worst
part of Django to me and I'd like to help to improve that in 1.3.
> Layout
> --
On Sun, Jul 11, 2010 at 12:16 PM, David Larlet wrote:
> Hi,
>
> Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
>> I'd like to propose a few extensions to Django's form library for 1.3.
> First of all, thanks or your proposal, the current form rendering is the
> worst part of Django to me
On Sun, Jul 11, 2010 at 12:16 PM, David Larlet wrote:
> Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
>> {% load custom_renderer %}
>> {% form myform %}
>>
>> Django would ship with {% form %} implementations of the 'as_p' and
>> 'as_ul' strategies, so getting 'as_p' rendering would mean
I'm glad to see that some serious thought is going into this issue!
This proposal sound very good (to me, at least) on the whole.
One thing that occurs to me, though, is that the people who are going
to want to customize form output are very frequently going to be the
people working mostly in the
Hi, thanks for the proposal!
One thing that might be worth looking at is templatetag namespaces.
There are a couple of issues that I see emerging with this changes.
It's been mentioned before that one would like to render with different {%
form %} tags different forms in one template, namespaces
What a fantastic proposal. I have some concerns, but I'm not sure if
any of them have to do with my misunderstanding.
1. The {% load %} mechanism can get ugly, fast. What if I am rendering
multiple different forms on the same page? {% load %} {% form %} {%
load %} {% form %} feels mildly unclean t
[please excuse the slight chop-up-and-reordering of your
original into my quoting]
On 07/11/2010 10:36 AM, Russell Keith-Magee wrote:
{% form myform %}
For what my vote may be worth, I'm -0 on this...
{% form myform field birthdate using calendar %}
and -1 on this
{% form myform field bi
I agree with Eric and my experiences back it up. Most of the people
who want to custom form widgets are the ones who are unprepared to dig
into Django/Python code. The easier we can make creating/extending
form widgets the better.
This looks like what I'll be sprinting on at DjangoCon. :)
Danny
On Mon, Jul 12, 2010 at 1:16 AM, David Larlet wrote:
> Hi,
>
> Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
>> {% load xhtml_p_forms %}
>> {% form myform %}
>
> Just a personal feedback, to me the rendering strategy is related to a whole
> project and should be defined in settings, it'
On Mon, Jul 12, 2010 at 2:14 AM, flo...@gmail.com wrote:
> I'm glad to see that some serious thought is going into this issue!
> This proposal sound very good (to me, at least) on the whole.
>
> One thing that occurs to me, though, is that the people who are going
> to want to customize form outpu
On Mon, Jul 12, 2010 at 1:35 AM, Javier Guerra Giraldez
wrote:
> On Sun, Jul 11, 2010 at 12:16 PM, David Larlet wrote:
>> Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
>>> {% load xhtml_p_forms %}
>>> {% form myform %}
>>
>> Just a personal feedback, to me the rendering strategy is rela
On Mon, Jul 12, 2010 at 5:35 AM, Iván Raskovsky wrote:
> Hi, thanks for the proposal!
> One thing that might be worth looking at is templatetag namespaces.
> There are a couple of issues that I see emerging with this changes.
> It's been mentioned before that one would like to render with differen
On Mon, Jul 12, 2010 at 3:16 AM, Daniel Greenfeld wrote:
> I agree with Eric and my experiences back it up. Most of the people
> who want to custom form widgets are the ones who are unprepared to dig
> into Django/Python code. The easier we can make creating/extending
> form widgets the better.
A
Good proposal overall. One thought I have in order to try and combat
the massive parameter list of {% form %} is to optionally add an
ending tag, as well as sub-tags:
{% form myform %}
{% using birthday=calendar %}
{% renderer "as_ul" %}
{% autocomplete "name_autocomplete" %}
{% do
On Sun, Jul 11, 2010 at 9:31 PM, André Eriksson wrote:
> {% form myform %}
> {% using birthday=calendar %}
> {% renderer "as_ul" %}
> {% autocomplete "name_autocomplete" %}
> {% doctype xhtml1 %}
> {% endform %}
i like this syntax; it's a lot more readable than a chain of
parameters o
On Sun, Jul 11, 2010 at 9:23 PM, Russell Keith-Magee
wrote:
> * Duplication. The 'left_table' flag needs to be applied to every use
> of the {% form %} tag on a page. If you're
> manually rolling out every field on a form, this is a lot of code duplication.
absolutely. see my answer to André fo
On Jul 12, 5:27 am, Javier Guerra Giraldez wrote:
> > 1) It introduces a clearer way of laying out settings.
> > 2) It leverages the template engine for specifying defaults in a
> > simple but ingenious way:
> > {% form myform %}
> > {% include "form_settings.django" %}
> > {% endform %}
> > --
Regarding the DOCTYPE problem, I don't think it's appropriate to set
the DOCTYPE as a setting for an entire project. As many have pointed
out, each bundled app could define a different DOCTYPE in their base
templates.
It doesn't make sense to apply a DOCTYPE setting to the context of a
form either
On Jul 12, 12:31 pm, André Eriksson wrote:
> Good proposal overall. One thought I have in order to try and combat
> the massive parameter list of {% form %} is to optionally add an
> ending tag, as well as sub-tags:
>
> {% form myform %}
> {% using birthday=calendar %}
> {% renderer "as_
k
On Mon, Jul 12, 2010 at 5:38 AM, Idan Gazit wrote:
> What a fantastic proposal. I have some concerns, but I'm not sure if
> any of them have to do with my misunderstanding.
>
> 1. The {% load %} mechanism can get ugly, fast. What if I am rendering
> multiple different forms on the same page? {%
On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote:
> Good proposal overall. One thought I have in order to try and combat
> the massive parameter list of {% form %} is to optionally add an
> ending tag, as well as sub-tags:
>
> {% form myform %}
> {% using birthday=calendar %}
> {% rend
On Mon, Jul 12, 2010 at 11:27 AM, Javier Guerra Giraldez
wrote:
> On Sun, Jul 11, 2010 at 9:23 PM, Russell Keith-Magee
> wrote:
>> * Duplication. The 'left_table' flag needs to be applied to every use
>> of the {% form %} tag on a page. If you're
>> manually rolling out every field on a form, th
On Mon, Jul 12, 2010 at 1:05 PM, Tai Lee wrote:
> Regarding the DOCTYPE problem, I don't think it's appropriate to set
> the DOCTYPE as a setting for an entire project. As many have pointed
> out, each bundled app could define a different DOCTYPE in their base
> templates.
>
> It doesn't make sens
On 07/12/2010 08:12 AM, Russell Keith-Magee wrote:
On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote:
Good proposal overall. One thought I have in order to try and combat
the massive parameter list of {% form %} is to optionally add an
ending tag, as well as sub-tags:
{% form myform %}
On Mon, Jul 12, 2010 at 3:11 PM, mattimust...@gmail.com
wrote:
>
>
> On Jul 12, 12:31 pm, André Eriksson wrote:
>> Good proposal overall. One thought I have in order to try and combat
>> the massive parameter list of {% form %} is to optionally add an
>> ending tag, as well as sub-tags:
>>
>> {%
On Mon, Jul 12, 2010 at 9:38 PM, Tim Chase
wrote:
> On 07/12/2010 08:12 AM, Russell Keith-Magee wrote:
>>
>> On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote:
>>>
>>> Good proposal overall. One thought I have in order to try and combat
>>> the massive parameter list of {% form %} is to opti
On Mon, Jul 12, 2010 at 9:47 PM, Russell Keith-Magee
wrote:
> On Mon, Jul 12, 2010 at 9:38 PM, Tim Chase
>> Looking back over the thread, I'm the only Tim, but I don't seem to see your
>> response (neither in my email nor via gmane). If you could disinter it from
>> your sent-mail folder and rese
On Jul 12, 8:12 am, Russell Keith-Magee
wrote:
> On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote:
> > Good proposal overall. One thought I have in order to try and combat
> > the massive parameter list of {% form %} is to optionally add an
> > ending tag, as well as sub-tags:
>
> > {% form
On Mon, Jul 12, 2010 at 8:16 AM, Russell Keith-Magee
wrote:
> On Mon, Jul 12, 2010 at 11:27 AM, Javier Guerra Giraldez
> wrote:
>> no, the P, UL (and my hypothetical left_table) would each one be a
>> class; you could import each one separately (or maybe several included
>> by default). in my ex
On Jul 12, 3:43 pm, Russell Keith-Magee
wrote:
> > Andre's idea is interesting and is certainly more readable.
>
> I'm having difficulty reconciling these two positions. My template tag
> is too complex because it requires you to remember the idiom FORM X
> FIELD Y USING Z; but a nested tag struct
On 07/12/2010 07:03 AM, Russell Keith-Magee wrote:
On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase
wrote:
[please excuse the slight chop-up-and-reordering of your
original into my quoting]
Only if you grant me the same liberty :-)
Fair's only fair :)
and REALLY -1.0e1 on this syntax-soup. Do
It appears my reply got eaten so I'm trying again.
On Jul 12, 3:43 pm, Russell Keith-Magee
wrote:
> I'm having difficulty reconciling these two positions. My template tag
> is too complex because it requires you to remember the idiom FORM X
> FIELD Y USING Z; but a nested tag structure with 4 dif
Hey Russ,
I think this is a great proposal so far!
Is there a way with the proposed solution for the template designer to
add custom attributes to a form field? If so, do you envision that
happening in the chrome layer?
Here's a use case:
The designer wants to render an email input field. They
Hi all,
I'm certainly excited to see improvements in the form rendering arena,
so thanks Russ for putting in the work here!
I work with Django plenty as a programmer, but in truth I work more as
a designer. And as a designer, I've spent more than my share of time
wrangling Django's existing templ
Hi Russ,
First of all, thanks very much for this proposal! Form rendering has
been a major pain point for us (thus the existence of
django-form-utils), and improving it is tops on my 1.3 wishlist. I
will also be at DjangoCon and eager to sprint in this area.
Django has a really good template syst
Russ/Carl:
Finally got a chance to catch up on the thread, and found Carl penned
a (lovely, much more detailed) version of what I had in mind.
In the end, forms is a repository of unusually common fail because
designers must figure out Python and a lot of how django works in
order to customize fo
I really like the idea of using Django templates instead of generating
markup in Python, which should enable designers (who don't know and
don't want to know Python) to customise markup in almost any way they
like. We just need to add a few hooks that will make it easier to
override specific templa
On Jul 12, 11:43 pm, Russell Keith-Magee
wrote:
>
> > On Jul 12, 12:31 pm, André Eriksson wrote:
> >> Good proposal overall. One thought I have in order to try and combat
> >> the massive parameter list of {% form %} is to optionally add an
> >> ending tag, as well as sub-tags:
>
> >> {% form m
Your proposal really needs to cater to two different audiences:
1. People who will use the new {% form myform %} where they just want
all the fields rendered without any fuss, much like {{ form }} now.
2. The tweakers that need to control every aspect of the each field
being rendered.
I'd say t
On Mon, Jul 12, 2010 at 11:01 PM, Tim Chase
wrote:
> On 07/12/2010 07:03 AM, Russell Keith-Magee wrote:
>>
> Yeah, I'll give you the point that your
> solution looks more elegant for individual field rendering, while one of my
> envisioned use cases was "I want this form exactly as it would normal
On Mon, Jul 12, 2010 at 11:29 PM, André Eriksson wrote:
> It appears my reply got eaten so I'm trying again.
>
> On Jul 12, 3:43 pm, Russell Keith-Magee
> wrote:
>> I'm having difficulty reconciling these two positions. My template tag
>> is too complex because it requires you to remember the idi
On Tue, Jul 13, 2010 at 12:28 AM, Preston Timmons
wrote:
> Hey Russ,
>
> I think this is a great proposal so far!
>
> Is there a way with the proposed solution for the template designer to
> add custom attributes to a form field? If so, do you envision that
> happening in the chrome layer?
Under
On Tue, Jul 13, 2010 at 3:03 AM, Gabriel Hurley wrote:
> Hi all,
>
> I'm certainly excited to see improvements in the form rendering arena,
> so thanks Russ for putting in the work here!
>
> I work with Django plenty as a programmer, but in truth I work more as
> a designer. And as a designer, I'v
On Tue, Jul 13, 2010 at 3:24 AM, Carl Meyer wrote:
> Hi Russ,
>
> First of all, thanks very much for this proposal! Form rendering has
> been a major pain point for us (thus the existence of
> django-form-utils), and improving it is tops on my 1.3 wishlist. I
> will also be at DjangoCon and eager
Hi Russ,
On Jul 13, 12:11 pm, Russell Keith-Magee
wrote:
> I have exactly 0 mad skillz as a front end guy, but I know that rich,
> pretty ajax widgets et al are necessary for a good user experience. My
> goal, as a backend guy with limited frontend skills, was to find a way
> to get the people wh
Thanks for the thoughtful reply, Russ! Just a couple quick points:
> As noted in my reply to Preston, this should easily possibly using
> chrome; I'm not sure I see why you disagree. The new options may be
> funcitonal, but from my reading of the HTML5 spec, they're functional
> in terms of UX, no
On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote:
> What exactly is your use case for something that designers want to
> customize in the raw widget that widget.render() doesn't expose?
That reminds me of one thing I'd very much like to see in any
refactoring of form/widget handling.
Hi Russ and Carl,
On Jul 14, 5:55 am, Carl Meyer wrote:
> Hi Russ,
>
> On Jul 13, 12:11 pm, Russell Keith-Magee
> wrote:
>
> > My manifestation of this problem is slightly different -- it's the
> > issue of how to ship a widget library that can be used anywhere. I
> > suppose one argument here i
Hi Tai,
On Jul 13, 8:42 pm, Tai Lee wrote:
> I wouldn't like to see widget libraries being packaged up with
> templates including conditional templates based on doctype. This seems
> messy, not friendly to override in your own templates, and effectively
> combining what should be multiple separat
Carl's proposal is exactly the kind of thing I was suggesting in my
first response to this thread (only better thought out and stated more
eloquently than I could have). Count me as a big +1 to it!
Thanks,
Eric Florenzano
--
You received this message because you are subscribed to the Google Grou
Hi Carl,
On Jul 14, 11:44 am, Carl Meyer wrote:
>
> I totally agree with this. I think very similar results can be
> achieved in the form-rendering system just with an optional parameter
> to a "form/render_form" tag that specifies a "base path" for finding
> template widgets for this form render
On Wed, Jul 14, 2010 at 3:55 AM, Carl Meyer wrote:
> Hi Russ,
>
> On Jul 13, 12:11 pm, Russell Keith-Magee
> wrote:
>> My concern about doing this entirely in templates is that it makes the
>> process of sharing a widget library a little more difficult. If it's
>> just code, then it just needs to
On Wed, Jul 14, 2010 at 5:58 AM, Nick Phillips
wrote:
> On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote:
>
>> What exactly is your use case for something that designers want to
>> customize in the raw widget that widget.render() doesn't expose?
>
> That reminds me of one thing I'd ver
On Wed, Jul 14, 2010 at 8:42 AM, Tai Lee wrote:
> Hi Russ and Carl,
>
> On Jul 14, 5:55 am, Carl Meyer wrote:
>> Hi Russ,
>>
>> On Jul 13, 12:11 pm, Russell Keith-Magee
>> wrote:
>>
>> > My manifestation of this problem is slightly different -- it's the
>> > issue of how to ship a widget library
On Jul 15, 1:14 am, Russell Keith-Magee
wrote:
> 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.
We also nee
On Jul 14, 4:15 pm, SmileyChris wrote:
> We also need d) Media hooks for a single widget - whether this can be
> done in only the template layer is a tricky problem...
>
> I'm still struggling with how you'd be able to render all the media at
> the top of your template for the form. I guess you'd
On Jul 14, 11:15 pm, Russell Keith-Magee
wrote:
>
> I'm not wildly enthusiastic about this. You've posted this snippet (or
> something like it) a couple of times, and every time my immediate
> reaction has been "You're in a twisty maze of endtemplatedir tags, all
> alike" :-)
>
> I can see what
/* 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)
>
On 15 čnc, 01:22, Carl Meyer wrote:
> On Jul 14, 4:15 pm, SmileyChris wrote:
>
> > We also need d) Media hooks for a single widget - whether this can be
> > done in only the template layer is a tricky problem...
>
> > I'm still struggling with how you'd be able to render all the media at
> > the
Don't forget support for HTML5 INPUT placeholders! Ideally these would
pull from a new attribute on the ModelForm object.
Would {% form %} output the tag, as well as the CSRF token, too?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
I'm a big +1 on the rendering with templates, as well as multiple
template tags, I see something like:
{% form new_user_form as_p %}
{% fieldset user_info %}
{% field username %}
{% field password %}
{% endfieldset %}
{% endform %}
or something similar, you could possibly even specify att
82 matches
Mail list logo