On Oct 13, 3:10 am, Benjamin Slavin wrote:
> There really is no such thing as "INSTALLED_APPS loading". I think
> you mean "model loading"... if so, it's not quite so simple. Maybe
> there's a way to make this approach work, but it's at least not as
> easy as "let's just add these two settings".
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 s
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 in documentation and cod
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 the general direction this
> 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
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 is missing now is some docume
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.
Thanks for offering up
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
> regroup will work fine for its
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 qui
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 this is
> something
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 th
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
> > particular path of solving the problem.
>
> I'm trying to avo
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 encounters a model defin
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 either ``prefix`` or ``msg
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
> to pull out a particular
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 particular issue with all
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 any
>> particular path of solving the problem.
>
> a v
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 them for longer peri
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
> particular path of solving the problem.
I'm trying to avoid taking on any Django projects at the moment other
tha
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 %}
{{ messag
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 defi
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
> logger-like API. I especial
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 backend support in g
I love the prefix idea. Seems like the best of both worlds. I also
agree that changing the name to either ``prefix`` or ``msg_prefix``
would probably be preferable, to explicitly indicate that the behavior
is different than the standard msg argument.
This would certainly satisfy my use case.
-we
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 best appoach for django
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 8
On Sat, Oct 10, 2009 at 10:52 PM, Simon Willison
wrote:
>
> On Twitter Malcolm pointed me here: http://code.djangoproject.com/ticket/5685
That's my ticket, and I had mostly forgotten about it.
As you've found out, there is no way to hook into the bootstrap
process. For signals, we just stuff t
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 receive
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
--~--~---
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
30 matches
Mail list logo
