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
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
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
> 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
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.
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
>
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
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
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
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
> >
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
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
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
>
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
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
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
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 %}
{{
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
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
>
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
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
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
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
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
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
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
28 matches
Mail list logo