On Mon, Nov 30, 2009 at 12:17 PM, Tobias McNulty <tob...@caktusgroup.com> wrote:
> Hi Russell,
>
> Thanks for all your feedback. I think I've got everything covered except
> for a few questions about the API (see below).
>
> On Fri, Nov 20, 2009 at 3:29 AM, Russell Keith-Magee
> <freakboy3...@gmail.com> wrote:
>> * contrib.messages.compat: I'm not a huge fan of the deprecation
>> approach here. What you've got in code here requires that when v1.4
>> comes around, we don't just need to delete deprecated methods, we (and
>> anyone else writing pluggable apps that need to support messages) need
>> to do code updates to remove usage of deprecated methods.
>>
>> The compat_add_message() and compat_get_messages() calls are
>> essentially just shortcuts - so why not formalize it as the official
>> API. i.e.,:
>>
>> from django.contrib import messages
>> messages.add_message(request, level, msg)
>>
>> When v1.4 comes around, we will need to tweak the implementation of
>> add_message() to remove the deprecated code path, but that's the
>> extent of the code changes required by us or any third party using
>> messages.
>>
>> This has the additional benefit of separating the implementation from
>> the API by a degree - if we ever choose to replace request.messages
>> with something that isn't bound to the request itself, the
>> message.add_message() api can remain.
>
> I like that. The compat_* family of methods were not intended for use
> outside of Django itself (some comments at the top of compat.py should say
> as much). Still, I can foresee a few situations in which you'd need to use
> them (or implement your own) if you're trying to build a project that uses
> both old- and new-style messaging. So, I think implementing an API that's
> decoupled from request might be a good thing.
>
> How would your approach work for the shortcut methods, like info, debug,
> etc.?
>
> I'm not sure I like the possibility that one could:
>
> from django.contrib.messages import debug
> debug('a message')
>
> As it may need to a lot of import renaming for the sake of not polluting the
> namespace with such generic names--and I don't want to force people to:
>
> from django.contrib import messages
>
> As not everyone may like having 'messages' in their namespace either.
Welcome to Python, home of:
from django.contrib import messages as i_dont_want_to_have_name_clashes
:-)
Seriously, this is exactly what 'import as' is designed for. If the
end user is worried about generic names, then both:
from django.contrib import messages as msg
msg.debug('foo')
and
from django.contrib.messages import debug as debug_msg
are viable workarounds.
> Maybe we need a getLogger()-like method? What about something like:
>
> from django.contrib.messages import get_message_store
> msg_store = get_message_store(request)
> msg_store.info('a message')
>
> I don't really like my choice of variable/method names, but you get the
> idea. Better naming ideas welcome. :)
I see what you're driving at here, but I'm not convinced it's worth
it. You're turing a simple method call into two, all to avoid a
possible naming collision that Python gives you the tools to avoid
anyway.
> Again, the only thing I can think of that still needs to be worked out is
> the details of the API and whether or not it should be decoupled from
> request. I'm in favor of the idea, I'm just not sure what solution makes
> the best sense yet (see above).
I'll take another look at this patch next week to make sure I haven't
missed anything. Assuming I don't find anything new and interesting
(and assuming you're happy with my response on the API issues), this
should be able to land in trunk in the very near future.
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.
