On Thu, Dec 3, 2009 at 2:39 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Thu, Dec 3, 2009 at 12:58 AM, Tobias McNulty <tob...@caktusgroup.com> > wrote: >> >> >> On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant <l.plant...@cantab.net> wrote: >>> >>> I just converted some code, and the API seems good to me. I had one >>> issue, which was the fact that I had some code which only had access >>> to the User object, and not the request object, which had to be re- >>> plumbed. The only place this change will be an issue is where it is >>> difficult to do that (e.g. if your code is being called from somewhere >>> else which you can't change). There is no reason this should hold us >>> back - storing messages on the User is really a hack, and if people >>> have a problem with not being able to do it any more (i.e. in Django >>> 1.4), they can use other hacks like storing the request in threadlocal >>> storage. >> >> *gasp* Did I really just hear a core committer condoning threadlocals? >> Storing messages on the user was bad, but not that bad. :) >> >>> >>> The simplest solution is to catch the exception in the generic views. >>> Another option is to add a 'fail_silently' keyword argument, >>> defaulting to False, like the mail sending API. It would need to be >>> added to all the shortcut functions, and used in the generic views and >>> anywhere that you cannot rely on there being a current authenticated >>> User. Docs should include something about it being intended for re- >>> usable apps. >> >> Good catch. fail_silently sounds good to me. I'll add. >> >> Tobias >> -- >> Tobias McNulty >> Caktus Consulting Group, LLC >> P.O. Box 1454 >> Carrboro, NC 27510 >> (919) 951-0052 >> http://www.caktusgroup.com >> >> -- >> >> 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. >> > > I haven't been paying as much attention to this thread as I should be > :(. However, I just read through the diff that was uploaded, and I'm > curious why the decision to go with functions with APIs like > messages.info(request, msg). Instead of request.messages.info(msg). > The latter reads far better to me.
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" 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.
