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
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" %}
> >
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.
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
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" %}
{%
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
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
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
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
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
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
[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
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
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
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
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'
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
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
> --
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
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
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
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
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,
--
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
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
25 matches
Mail list logo