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

Re: Enhanced URL Resolver Match

Sounds great Russ. I have created a ticket for this issue: http://code.djangoproject.com/ticket/13922 Once you do a tear-down, and if things look good, let me know and I'll start taking a stab at documentation. Thanks! Nowell On Jul 10, 4:35 am, Russell Keith-Magee

Re: Django Model Related Manager Enhancements

Hey Russ, On Jul 10, 4:21 am, Russell Keith-Magee wrote: > On Thu, Jul 8, 2010 at 10:45 PM, Nowell Strite wrote: > > Recently I started working on a project (django-versions) to enable > > versioning of model data with Mercurial. In doing so, I came

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

On Jul 11, 12:14 am, Russell Keith-Magee wrote: > > So you can't put reverse now in settings.py unless there is some > > late-binding construct, like > > > LOGIN_URL = RevLink('accounts:login', account_type='user') > > You shouldn't have to put reverse() calls into

Re: Regression problem on admin date format

Hi, I have confirmed the bug with other non speaking people and I have sent an e-mail to django-i18n group to point out the problem. I have also contacted Marc and he has confirmed that the problem exists. Sorry for the insistence but in my opinion this is a blocker bug. Best regards, --

Re: Ticket #5373

On Sun, Jul 11, 2010 at 17:31, Russell Keith-Magee wrote: >> wrote: >> I'm not quite sure I understand. Does that mean we can have >> conflicting verbose_names? My mental unrolling of your advice brings >> me to: > > The two verbose names are

Re: Ticket #5373

On Sun, Jul 11, 2010 at 12:53 PM, Lachlan Musicman wrote: > On Fri, Jul 9, 2010 at 00:00, Russell Keith-Magee > wrote: >> On Thu, Jul 8, 2010 at 3:55 PM, Lachlan Musicman wrote: >>> Hola, >>> >>> I'm new to this dev thing, but I've