It's also a good thing,  I realized last night, because it means one can use
messages from a reusable app without requiring that all projects using the
app enable messages.

Cheers,
Tobias

Sent from a mobile phone, please excuse any typos.

On Dec 3, 2009 6:25 AM, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

On Thu, Dec 3, 2009 at 2:39 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >
On Thu, Dec 3, 2009 at ...
That was a late change. There are two reasons behind it:

Firstly, there is a backwards compatibility problem. Legacy code won't
have the messages attribute on request, because it won't have the
messages middleware. Earlier versions of the code had a
'compat_add_message' function that had a fallback to using
request.user.message_set if request.messages wasn't available.
However, this would have meant introducing a function in 1.2 that was
deprecated at time of introduction - we would have needed to change
code in 1.2 to use the compatibility function, and change it again
when 1.4 came around.

I suggested that the compatibility function could actually be the
normal interface. That way, when 1.4 comes around, we can just update
the implementation of the 'add_message' function to remove the
deprecated code path.

The second reason is architectural. Using messages.info(request, msg)
decouples the process of sending messages from the message store on
the request itself. If we ever chose to change the way the message
store works, we're not bound to maintaining a request.messages data
structure.

I will admit that this second reason smells a little of YAGNI. I have
no idea what change would necessitate decoupling the message store
from request (other than the obvious reverse case of the
backwards-compatibility function). The backwards compatibility issue
is the primary reason for the change; the architectural reasoning is
very much "after the fact".

Yours,
Russ Magee %-)

-- You received this message because you are subscribed to the Google Groups
"Django developers" g...

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.


Reply via email to