Re: Revised revised form rendering

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 > the template

Re: [GSoC] Revised form rendering

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

Re: [GSoC] Revised form rendering

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

Re: [GSoC] 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

Re: [GSoC] Revised form rendering

. 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 Propos

Re: [GSoC] Revised form rendering

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

Re: [GSoC] Revised form rendering

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

Re: [GSoC] Revised form rendering

ted nicely. >> >> >> GSoC 2011 Proposal - Revised form rendering >> >> >> Hi my name is Gregor Müllegger. I'm a Computer Science student in Germany at >> the University of Augsburg currently in the fourth year of my

Re: [GSoC] Revised form rendering

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,

Re: [GSoC] 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

Re: [GSoC] Revised form rendering

On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger <gre...@muellegger.de> 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 - R

Re: Revised form rendering

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

Re: Revised form rendering

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

Re: [GSoC] Revised form rendering

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 >> >> >> ... >

Re: Revised form rendering

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

Re: Revised form rendering

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

Re: [GSoC] Revised form rendering

, 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 > > > Hi my name is Gregor M

[GSoC] Revised form rendering

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 Germany

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

/* 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) >  

Re: Proposal: Revised form rendering

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 >

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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) >

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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.

Re: Proposal: Revised form rendering

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,

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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 > >>

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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 > >

Re: Proposal: Revised form rendering

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

Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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 >>>

Re: Proposal: Revised form rendering

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 >>

Re: Proposal: Revised form rendering

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:

Re: Proposal: Revised form rendering

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 >

Re: Proposal: Revised form rendering

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 >>

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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 %} >  

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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" %} > >

Re: Proposal: Revised form rendering

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.

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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" %} {%

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

[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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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'

Re: Proposal: Revised form rendering

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

Re: Proposal: Revised form rendering

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 > --

Proposal: Revised form rendering

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