> >> 7. Requests in forms
>
> >> I suspect the answer on this one will be no for the simple reason of
> >> backwards compatibility. A request attribute is only really useful if
> >> it is ubiquitous, and there's no way to make it ubiquitous without
> >> breaking backwards compatibility. Truth be to
On Thu, Jun 3, 2010 at 11:32 PM, petr.marhoun wrote:
> On Jun 3, 2:57 pm, Russell Keith-Magee
> wrote:
>> On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote:
>> > Hello,
>>
>> > I would like to propose some improvements for django.forms. But it is
>> > seven quite independent proposals - one mai
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> - It seems that it is not possible to say if form has fieldsets
> (fieldsets method even construct fieldsets if meta attribute is not
> set) - I think it is useful to know it in templates.
I spoke too quickly here: this is a relevant API question. In for
Hi Petr,
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> I have some notes to forms-utils:
> - The code says: "if legend is None: legend = name". I dislike it - I
> want to have possibility not to set legend. I think that if legend is
> not set it should be "None" in fieldset.
Yes, this is one of the
Hello,
> One thing form-utils does differently from your proposal is that it
> defines each fieldset as a two-tuple (like admin fieldsets), with a
> name as the first element and the dictionary of additional info as the
> second element. One advantage of having a fieldset "name" is that it
> also
On Jun 3, 8:57 am, Russell Keith-Magee
wrote:
> 5. Parameters "template" and "attrs" for forms, formsets, fieldsets,
> forms, (bound) fields and widgets
> 6. Support for (X)HTML5 and legacy HTML
>
> I strongly suspect that these two may be covered by something I
> discussed with Jacob at DjangoCon
Hey Petr,
On Jun 3, 11:32 am, "petr.marhoun" wrote:
> OK, more details: If fieldsets would be defined, fields would be
> concatenation of fields from individual fieldsets. So methods
> as_table, as_ul and as_li and "for field in form" would work as now.
> But if you want to really use fieldsets,
On Jun 3, 2:57 pm, Russell Keith-Magee
wrote:
> On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote:
> > Hello,
>
> > I would like to propose some improvements for django.forms. But it is
> > seven quite independent proposals - one mail would be to long, seven
> > emails would too many emails. So
Hi,
what about adding one more layer on top of forms:
a page object
why?
1) because it would be nice to have other widgets besides forms, too (e.g. a
(ajax-)table (like in the admin views)
2) having a page object could ease the mess with media files from forms and the
rest of a page (e.g. avoid
On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote:
> Hello,
>
> I would like to propose some improvements for django.forms. But it is
> seven quite independent proposals - one mail would be to long, seven
> emails would too many emails. So I have created wiki page - is it a
> good procedure?
It'
I think grouping issues and features requests is always a good
thing :)
Now about the "Model fields with not-default values".
With 1.2 something like that landed to override the widget for fields
on ModelForms, but I agree that sometimes you need to change a label
or help text for a specific form
Hello,
I would like to propose some improvements for django.forms. But it is
seven quite independent proposals - one mail would be to long, seven
emails would too many emails. So I have created wiki page - is it a
good procedure?
The wiki page:
http://code.djangoproject.com/wiki/ImprovementsForDj
On Wed, Oct 22, 2008 at 07:17:56PM +1100, Malcolm Tredinnick wrote:
> > I think it would be nice if you could call
> > mark_safe on the label attribute of a form field so it doesn't get
> > escaped in _html_output. Currently if you want to put html in labels,
> > it seems that you have to copy and
On Wed, Oct 22, 2008 at 07:17:56PM +1100, Malcolm Tredinnick wrote:
> On Sat, 2008-10-18 at 12:48 -0700, Jesse Young wrote:
> > I think it would be nice if you could call
> > mark_safe on the label attribute of a form field so it doesn't get
> > escaped in _html_output. Currently if you want to pu
On Sat, 2008-10-18 at 12:48 -0700, Jesse Young wrote:
> > 3. Meta attribute formfield_kwargs for model forms
>
> It seems like the arguments to form fields can already be customized
> fairly easily using formfield_callback? In your example, I think you
> could accomplish the same thing using for
I don't have particularly strong feelings about this, with the exception
of a few things noted below...
On Thu, 2008-10-16 at 20:09 -0700, pm13 wrote:
> I would like to propose five quite isolated improvements for
> django.forms. But I think it is better to write about them in one
> email - other
On Oct 18, 9:48 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> > 3. Meta attribute formfield_kwargs for model forms
>
> It seems like the arguments to form fields can already be customized
> fairly easily using formfield_callback? In your example, I think you
> could accomplish the same thing using
On Oct 18, 6:44 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> Some of these changes I think are very valuable, especially CSS
> classes. The formfield_kwargs I don't think is the right approach, but
> possibly a method which could be called, as a lot of times I'm
> overriding __init__ and it's qui
> 3. Meta attribute formfield_kwargs for model forms
It seems like the arguments to form fields can already be customized
fairly easily using formfield_callback? In your example, I think you
could accomplish the same thing using formfield_callback like this:
formfield_callback = lambda f: f
Some of these changes I think are very valuable, especially CSS
classes. The formfield_kwargs I don't think is the right approach, but
possibly a method which could be called, as a lot of times I'm
overriding __init__ and it's quite messy, just to change the queryset
for a form.
I would personall
I would like to propose five quite isolated improvements for
django.forms. But I think it is better to write about them in one
email - otherwise there would not be complete answers for the
problems. (More specifically, proposal 5 is very useful for proposals
1 and 2. And proposals 3 a 4 are very u
21 matches
Mail list logo
