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
Is nobody interested?
I'm using this in production for auditing purposes and works just fine.
If only it were built in, then I wouldn't have to monkeypatch :)
I've rebased it to trunk again and it still works.
On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote:
> I know that queryset.upd
Hi Mark,
> For 'polymorphic.polymorphic_model' it would be 'polymorphic'.
Is that correct this didn't work at all (or didn't work properly)
before your patch, and now works properly, so one can put
"polymorphic.polymorphic_model" into their INSTALLED_APPS and
everything would work?
Should one impo
Hi Dennis --
I'm not totally thrilled with this proposal, though perhaps there's
some points I just don't get. As it is, though, I'm -0 on the idea.
update() is supposed to be an optimization that's "close to the metal"
of the database; adding potentially-hidden slow code to the mix rubs
me the wr
On Wed, Jul 28, 2010 at 9:37 AM, Dennis Kaarsemaker
wrote:
> Is nobody interested?
>
> I'm using this in production for auditing purposes and works just fine.
> If only it were built in, then I wouldn't have to monkeypatch :)
>
> I've rebased it to trunk again and it still works.
>
> On wo, 2010-0
On Tue, Jul 27, 2010 at 2:39 AM, Mark Sandstrom
wrote:
> I've added a ticket with a patch for automatically discovering models within
> a package without using the app_label Meta attribute.
I can't quite follow what the motivation is here -- could you perhaps
explain *why* you created this patch?
On Wed, Jul 28, 2010 at 10:34 PM, Jacob Kaplan-Moss wrote:
> On Tue, Jul 27, 2010 at 2:39 AM, Mark Sandstrom
> wrote:
>> I've added a ticket with a patch for automatically discovering models within
>> a package without using the app_label Meta attribute.
>
> I can't quite follow what the motivati
On Wed, Jul 28, 2010 at 12:09 PM, Rajeev J Sebastian
wrote:
> I think it might be useful for people refactoring their ever-growing models.py
That's maybe part of what I don't understand: I can't ever say I've
seen a models.py so big that I felt the need to split it up. Or
rather, I have, but in e
On wo, 2010-07-28 at 12:02 -0500, Jacob Kaplan-Moss wrote:
> Hi Dennis --
>
> I'm not totally thrilled with this proposal, though perhaps there's
> some points I just don't get. As it is, though, I'm -0 on the idea.
> update() is supposed to be an optimization that's "close to the metal"
> of the
On Wed, Jul 28, 2010 at 10:45 PM, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 12:09 PM, Rajeev J Sebastian
> wrote:
>> I think it might be useful for people refactoring their ever-growing
>> models.py
>
> That's maybe part of what I don't understand: I can't ever say I've
> seen a models.
On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker
wrote:
> This would add boilerplate to each class and makes it nontrivial to do
> update() tracking for third party applications. I don't see why pre/post
> update signals are worse than pre/post save and delete.
Because the save/delete signals
On wo, 2010-07-28 at 13:43 -0500, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker
> wrote:
> > This would add boilerplate to each class and makes it nontrivial to do
> > update() tracking for third party applications. I don't see why pre/post
> > update signals are
On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker
wrote:
> As implemented in my github branch it is called once (well, twice, pre
> and post) per update() statement, not once per object.
Okay, I missed that -- sorry.
Doesn't really change how I feel about the feature, though: I don't
see the p
On wo, 2010-07-28 at 14:20 -0500, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker
> wrote:
> > As implemented in my github branch it is called once (well, twice, pre
> > and post) per update() statement, not once per object.
>
> Okay, I missed that -- sorry.
>
> Do
On Wed, Jul 28, 2010 at 12:02 PM, Jacob Kaplan-Moss wrote:
> Hi Dennis --
>
> I'm not totally thrilled with this proposal, though perhaps there's
> some points I just don't get. As it is, though, I'm -0 on the idea.
> update() is supposed to be an optimization that's "close to the metal"
> of the
On Wed, Jul 28, 2010 at 2:46 PM, Jeremy Dunck wrote:
...
> A bit of a seque, but I think this is a useful way to DRY this common need:
> http://djangosnippets.org/snippets/2117/
segue, but non sequitur is what I meant in any case. :-)
--
You received this message because you are subscribed to
Hi,
I'm running trunk and I found an issue where my model's tablename
contains uppercase characters.
svn praise says this broke in r13363
r13363 russellm # Use pg_get_serial_sequence to get the
underlying sequence name
r13363 russellm # from the table name and column name
(av
The patch here [1] fixes this if anyone feels like reviewing. This bug is
preventing me from using trunk on several projects at present, so it would
be great to get the patch checked in. It also fixes a number of other
problems people have been reporting, I believe.
Simon
[1] http://code.djangopr
18 matches
Mail list logo
