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
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
> I'm mostly just commenting on the API here. I've only read the patch a
> couple of times and haven't fully absorbed the inner details yet.
>
> You've certainly put a lot of work into this and I really don't want to
> seem to be arbitrarily dismissing your ideas (which I'm definitely not).
> Howe
On 18 Ún, 18:21, Brian Rosner <[EMAIL PROTECTED]> wrote:
> > Is there any good reason why the "fieldsets" option of ModelAdmin (in
> > newforms-admin) shouldn't be pushed down into the newforms library?
> > What I'm doing right now by overriding change_form.html would be even
> > easier if I could
I tried to find a solution for tickets #3512 (Add "required" & "error"
CSS classes to form rows in as_* methods) and #3515 (CSS improvements
for newforms). I added a patch and I got an advice to bring this topic
here.
I would like to propose new attribute for Widget.__init__ -
outer_attrs. Widget
I use newforms-admin branch and I like it very much. And I have some
ideas for possible improvements for internationalization.
1. Capitalized verbose names for models
Now the preferred format is:
class Contact(models.Model):
email = models.CharField(verbose_name=_('email'))
class ContactFo
On 10 Zář, 02:32, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> > But I think anyway that there should be some kind of caching by
> > default. It isn't only my problem - it may be quite usual to use
> > inlines with more rows and with foreign keys. (I will try to give
> > better description an
> > I created example of the first solution:
> >http://code.djangoproject.com/ticket/5372
>
> The patch you attached in that ticket looks like it will solve your
> problem, and in fact, you can just subclass TabularInline or
> StackedInline, override the formfield_for_dbfield on you subclass, and
I have a problem with this changeset. I have some inlines with foreign
keys. By default there is one SQL query for each row - result is not
cached. So I used this code in formfield_for_dbfield:
if isinstance(db_field, models.ForeignKey):
kwargs['cache_choices'] = True
The argument cache_cho
Ivan Sagalaev napsal:
> pm13 wrote:
> > I noted that you would like to implement auto-escaping. It will mean
> > third dimension of potential problems with strings.
>
> Why that? Unicode branch is designed to work with byte strings only for
> backward compatibility,
I started using unicode-branch. Thank you very much for your work - I
had many problems with strings in django but they are solved now.
I had some difficulties with the change (and I submitted some tickets
with patches). There are complex interactions - unicode vs. non-
unicode strings and lazy
12 matches
Mail list logo
