On Friday 16 October 2009 02:04:35 Tobias McNulty wrote:
> On Thu, Oct 15, 2009 at 7:03 PM, SmileyChris <smileych...@gmail.com>
wrote:
> > If we are to slowly deprecate this functionality, I think that we
> > should do effectively the same thing.
> > Leave user messages as-is and use something like this as the
> > default message storage:
>
> Just to make sure I understand this correctly, let me try to
> summarize what this would mean:
>
> * the proposed app controls {{ messages }} and is responsible for
> retrieving anything set in the Message model
>
> * old apps that call user.message_set.create will still get their
> messages to the screen, assuming the project uses {{ messages }} in
> the template
>
> * old apps that call get_and_delete_messages or iterate through
> the Message.objects.all() manually will NOT see any messages that
> were stored in the session or a cookie, but they will continue to
> see messages created the old way
>
> * judging from your code, the new app will NOT store any messages
> in the old Message model, it will only read them
>
> * the standard template code:
>
> {% if messages %}
> <ul>
> {% for message in messages %}
> <li>{{ message }}</li>
> {% endfor %}
> </ul>
> {% endif %}
>
> will continue to work untouched after the update. For those that
> choose to leverage it, a {{message.level}} (or otherwise named
> attribute) will also be available.
>
> * since we are tying ourselves to the {{ messages }} variable,
> this probably means that the app should be called 'messages'.
> There has been some hesitation about this. Are we in the clear
> now that we have a potential upgrade path from the old API? Or is
> there still concern about naming?
I've been catching up on this and watching this evolve, and this
proposal now looks solid IMO.
I think you should call this 'messages' consistently throughout, in
terms of the names of modules/variables/settings. If you need to
changed some documentation regarding the existing message
functionality, call that 'user messages' to distinguish it.
With regard to the deprecation schedule, normally we add a
PendingDeprecationWarning before the DeprecationWarning. If code in
core/contrib continues to use user messages for 1.2, it will emit a
PendingDeprecation, which is bad practice really - it's not fair to
users to emit warnings that aren't their fault and that they can't
fix, and it's not good for core code to be using something that we are
saying everyone else shouldn't.
I think this means that either the deprecation cycle would have to
pushed back one (i.e. pending deprecation warning in 1.3, deprecation
in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2. I
would strongly prefer the latter, and this would affect my vote: I
don't want two messaging systems in Django, and if user messages are
not deprecated, then we do have two systems.
Luke
--
You meet a lot of smart guys with stupid wives, but you almost
never meet a smart woman with a stupid husband. (Erica Jong)
Luke Plant || http://lukeplant.me.uk/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
