On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > Secondly, I share Chris' concern about overloading 'messages'. This > overlaps with the bikeshed issue of what to call the new contrib > package - whatever name is picked for the contrib package should > probably be reflected in the context variable, etc. > > Lastly, one issue that seems unaddressed is the transition plan for > replacing user.message_set. The preamble to the wiki page makes a > compelling argument for ditching message_set, but remains silent on a > proposal for how Django (as a project) should be treating this new > alternative. > > The solution might well be "use it if you want, ignore it if you > don't", but given the problems with user.message_set, it might be > worth giving some thought to a deprecation/transition plan.
This may be adding undue complexity, but I wanted to throw it out and see what you thought anyway. I think a possible solution to Russ' last two points may indeed be overloading the "messages" template variable. What I'm thinking is that we keep the message_set (of course) and add the new "request.messages.*" API, but completely remove the messages part of the auth context_processor and have the default backend for the new system pull both for the first release (purely for backward comparability). Messages from the old message_set system could get a default level in the new system. This shouldn't be an issue since the people using it will likely be existing projects where they won't be using any level information in their templates. We couple this combined backend with settings that will allow you to easily disable the DB part of the backend (or make it clear how to and strongly suggest switching backends), and provide a setting for the default message level that defaults to INFO. I think this could ease transition as the two systems could live together for the first release. The subsequent releases could switch the default backend to the existing fallback one, and then eventually remove the message_set part of the auth app all together. I do recognize that this may create more confusion than is necessary. It may also be an unacceptable performance drain on the new system to support the old at all. I just think as someone who has projects that still use the message_set, and especially considering the 3rd party apps out there which may use it as well, it might be a nice balance to be able to mix in the new and better while having as little impact on the templates as possible. Technically, this may be more of a challenge than it's worth however. The current auth context_processor is in core, and it just really feels wrong to me to couple this new app to either core or contrib.auth. We could just remove the "messages" part of the auth context_processor and add a new processor from the new app to the list of defaults that will provide all of the "messages". And actually, we'll need to at least override that part of the auth context_processor anyway, or else we'll still get a db hit for every request with a logged in user due to the call to user.get_and_delete_messages. Sorry about throwing my brainstorm at you. Perhaps it'll spark someone else's solution. Thanks, Paul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~----------~----~----~----~------~----~------~--~---
