Re: #7539 Add ON DELETE and ON UPDATE support

2009-10-12 Thread Jani Tiainen
Michael Glassford kirjoitti: > > > Jani Tiainen wrote: >> Is there anyone working for this ticket? >> >> There seemed to be few patches but then a silence. >> >> I would be interested in to help/implement that feature since it's very >> highly needed feature in our own code. >> > > I am. The

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Tue, Oct 13, 2009 at 12:13 AM, Chris Beaven wrote: > One thought: It would be backwards incompatible to change > {{ messages }}, it's already being used for User messages. To avoid > confusion, I have consistently steered away from using the term > "messages" by itself

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Chris Beaven
On Oct 13, 8:34 am, Tobias McNulty wrote: > Before we get too far, I'd appreciate hearing feedback from one or > more of the core devs (and from some of the folks who were involved in > this discussion back when it was happening on the ticket) on the wiki > page[1] and

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

2009-10-12 Thread Benjamin Slavin
> Maybe I'm oversimplifying this - and I'm sure if you'll tell me if I > am ;-) - but how about the following: add a setting called e.g. > SETUP_CALLBACKS  (or whatever name you prefer) which will be an > iterable (say, tuple) of callables which are called from > Settings.__init__ in the same way

Re: Patch: adding a msg parameter to assertContains and similar methods in the test client

2009-10-12 Thread Russell Keith-Magee
On Tue, Oct 13, 2009 at 12:29 AM, Christian Oudard wrote: > > I think using it as a prefix is a good solution. Updated the patch, > and attached it to the ticket. Should we reopen the ticket? Done. I've also marked it for v1.2 so I remember to check it in. All that

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Mon, Oct 12, 2009 at 3:06 PM, Paul McLanahan wrote: > Tobias: Are you planning on coding up a proposal app? It doesn't sound > like there's far to go from a branch or fork of django-notify. I > should have some time to contribute to the code or testing if you need > it.

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Paul McLanahan
On Mon, Oct 12, 2009 at 2:32 PM, Tobias McNulty wrote: > For the record I have no personal need for this feature (and hence > strong feelings about it), but nor do I see why adding it would be a > bad thing IF the need is actually there.  Right now it sounds like >

Re: Session/cookie based messages (#4604)

2009-10-12 Thread David Cramer
Sorry for the misunderstanding, I was talking specifically on retrieval of messages. I definitely see no reason not to keep it in line with the logging module in terms of errors/warnings/info messages. However, using things to "retrieve all error messages" should be left up to the user. It's no

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Mon, Oct 12, 2009 at 2:02 PM, David Cramer wrote: > I'm -1 on adding .errors or whatever. The main reasoning being that "levels" > are simply numeric values (even though django-notices does provide default > labels for its built-ins). Regroup is very easy and I don't think

Re: Session/cookie based messages (#4604)

2009-10-12 Thread David Cramer
I'm -1 on adding .errors or whatever. The main reasoning being that "levels" are simply numeric values (even though django-notices does provide default labels for its built-ins). Regroup is very easy and I don't think this is something that needs built-in, as there's no better way to optimize it

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

2009-10-12 Thread Vinay Sajip
On Oct 12, 5:04 pm, Simon Willison wrote: > On Oct 12, 9:03 am, Benjamin Slavin wrote: > > > That means: I'm strongly in favor of any hook to allow code to be run > > before the Django environment is setup, and I'm not tied to any > >

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

2009-10-12 Thread Marty Alchin
On Mon, Oct 12, 2009 at 12:09 PM, Jeremy Dunck wrote: > Also, I bet Marty knows this area well from his book work. Actually, I didn't research much on the initialization process as a whole, if there indeed is such a beast. I started with what happens when Python actually

Re: Patch: adding a msg parameter to assertContains and similar methods in the test client

2009-10-12 Thread Christian Oudard
I think using it as a prefix is a good solution. Updated the patch, and attached it to the ticket. Should we reopen the ticket? On Oct 12, 11:36 am, Wes Winham wrote: > I love the prefix idea. Seems like the best of both worlds. I also > agree that changing the name to

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Paul McLanahan
On Mon, Oct 12, 2009 at 12:11 PM, Tobias McNulty wrote: > I have no particular issue with allowing messages to be iterated in > full and/or by type.  We could also just sort the messages and let you > use {% regroup messages by tag %}, but I suppose you want the ability >

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Mon, Oct 12, 2009 at 11:53 AM, Paul McLanahan wrote: > For the potential API... > > http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI > > It would be really nice if one could optionally iterate over the > message lists separately. For example: I have no

Re: Best place for code that processes stuff from settings.py once (for logging implementation)

2009-10-12 Thread Jeremy Dunck
On Oct 12, 2009, at 11:04 AM, Simon Willison wrote: > > On Oct 12, 9:03 am, Benjamin Slavin wrote: >> That means: I'm strongly in favor of any hook to allow code to be run >> before the Django environment is setup, and I'm not tied to

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Mon, Oct 12, 2009 at 11:52 AM, David Cramer wrote: > I would definitely say it needs to be configurable then at the least. > As using cookies to send messges is fine if you guarantee the entity > is removed onthe next hit. Otherwise it becomes a performance issue > storing

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Paul McLanahan
For the potential API... http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI It would be really nice if one could optionally iterate over the message lists separately. For example: {% if request.messages.error %} {% for message in request.messages.error %} {{

Re: Session/cookie based messages (#4604)

2009-10-12 Thread David Cramer
I would definitely say it needs to be configurable then at the least. As using cookies to send messges is fine if you guarantee the entity is removed onthe next hit. Otherwise it becomes a performance issue storing them for longer periods of time. While I don't think that is common it should

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Mon, Oct 12, 2009 at 11:42 AM, Paul McLanahan wrote: > For me, the best solution would be a combination of django-notify and > django-notices. django-notify for their fallback backend and the > interchangeable backend support in general, and django-notices for the >

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Paul McLanahan
On Sat, Oct 10, 2009 at 2:05 PM, David Cramer wrote: > The proposal per your email is more or less how django-notices works. For me, the best solution would be a combination of django-notify and django-notices. django-notify for their fallback backend and the interchangeable

Re: Session/cookie based messages (#4604)

2009-10-12 Thread Tobias McNulty
On Mon, Oct 12, 2009 at 10:21 AM, David Cramer wrote: > I also don't think this problem is being addressed here. Yes you could > pass messages to the context, but you would lose the ability to > retrieve those variably. I believe storing it in the existing session > is the

Re: Session/cookie based messages (#4604)

2009-10-12 Thread David Cramer
I also don't think this problem is being addressed here. Yes you could pass messages to the context, but you would lose the ability to retrieve those variably. I believe storing it in the existing session is the best appoach for django's builtin support. Sent from my iPhone On Oct 10, 2009, at

can't pass instance=None to inline formset - #11872

2009-10-12 Thread Tobias McNulty
Another quick bug fix that should be ready for review/check-in: http://code.djangoproject.com/ticket/11872 -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ You

404 debug pages should show the name of the tried urlpattern - #9310

2009-10-12 Thread Tobias McNulty
In case it's not already on someone's radar, the patch on this ticket could use a review at some point: http://code.djangoproject.com/ticket/9310 Thanks - Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com

Re: #7539 Add ON DELETE and ON UPDATE support

2009-10-12 Thread Michael Glassford
Jani Tiainen wrote: > Is there anyone working for this ticket? > > There seemed to be few patches but then a silence. > > I would be interested in to help/implement that feature since it's very > highly needed feature in our own code. > I am. The silence is due to a couple of problems I've

#7539 Add ON DELETE and ON UPDATE support

2009-10-12 Thread Jani Tiainen
Is there anyone working for this ticket? There seemed to be few patches but then a silence. I would be interested in to help/implement that feature since it's very highly needed feature in our own code. -- Jani Tiainen --~--~-~--~~~---~--~~ You received this

Re: Does #3591 need solving? (was Re: Django 1.2 roadmap and schedule)

2009-10-12 Thread Vinay Sajip
On Oct 12, 12:56 am, Russell Keith-Magee wrote: > Sorry? Django importing magic? "from app.models import MyModel"... is magic? I didn't say "model importing". I'm talking about things like the restrictions on what you can import in settings.py, and ticket #8193 (double