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.