Outstanding question regarding storage/backend notwithstanding, I uploaded a new patch here:
http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-6399c12d1773.diff Luke, it includes a note that fail_silently only hides the error when messages is disabled. I'm going to give this a final whirl by converting a project or two. Cheers, Tobias On Sat, Dec 5, 2009 at 2:05 PM, Tobias McNulty <tob...@caktusgroup.com> wrote: > It looks like I mis-read the original question about storage vs. > backend, so thanks for picking this up Luke. > > I don't have much to add to your argument except to say that it would > be non-trivial to move to a more strictly organized/named setup. > > Cheers, > Tobias > > On Sat, Dec 5, 2009 at 12:51 PM, Luke Plant <l.plant...@cantab.net> wrote: >> On Saturday 05 December 2009 13:40:40 Russell Keith-Magee wrote: >> >>> * I'd rather the AddMessageFailure have a more generic name (like >>> MessageFailure). I don't see any need to be task specific in the >>> exception class name. >> >> Another thing here we should think about: at the moment, fail_silently >> only silences the error for the messages framework not being >> installed. But there are a lot of other ways the messages backend >> could potentially fail. Should we silence those errors too? I would >> suggest not, or there should be a separate keyword argument for that. >> But this should be clear in the docs. >> >>> * I don't know why I didn't pick this up earlier, but the emerging >>> convention for pluggable backends is for the user to specify the >>> name of the module, and for the module to have a predictable class >>> name. i.e - each storage backend module should have a >>> "StorageEngine" class, and the user specifies the name of the >>> module. There is also an emerging convention to call the pluggable >>> bits 'backends', rather than picking a name like 'storage'. Net >>> result: the user should be configuring >>> MESSAGE_BACKEND="django.contrib.messages.backends.user_messages" >>> rather than >>> MESSAGE_STORAGE = >>> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorag >>> e' >> >> Hmm, it is 'emerging' only in that several established subsystems use >> it (db, session, cache) and the e-mail stuff just added uses this >> convention. There are other established conventions in the code base, >> some of which are more recent IIRC: >> >> * that used by the file storage classes, file upload handlers and the >> authentication backend where the specific class is referred to. >> * that used by the template loaders, where the specific callable >> is referred to. >> >> I actually much prefer the explicit naming of a class/callable. Here >> are some arguments in favour of this method, some of which are >> stronger than others: >> >> * you can put multiple backends in one file if you want to, and you >> are not forced to duplicate imports or get creative with module >> names if you happen to have several backends that really belong >> in the same module. >> >> * it is much more obvious for someone who does not know the code, >> since it doesn't rely on a convention of a class with a certain >> name. If they see the setting for MESSAGE_STORAGE pointing to >> a class, they will immediately know where the implementation is, >> whereas if it points to a module and the module contains multiple >> classes, they will have to guess which class is the main one, or >> browse docs/source code. >> >> * it makes it less verbose and confusing if one backend refers to >> another (as happens with messages), because all the classes >> have different names, rather than having the same name. We >> currently have: >> >> from django.contrib.messages.storage.fallback import FallbackStorage >> ... >> class LegacyFallbackStorage(FallbackStorage): >> storage_classes = (UserMessagesStorage,) + >> FallbackStorage.storage_classes >> >> which would need to be changed to: >> >> from django.contrib.messages.backends import fallback >> ... >> class StorageEngine(fallback.StorageEngine): >> storage_classes = (UserMessageStorageEngine,) + >> fallback.StorageEngine.storage_classes >> >> or, using 'as' for the import: >> >> from django.contrib.messages.backends.fallback import StorageEngine \ >> as FallbackStorageEngine >> ... >> class StorageEngine(FallbackStorageEngine): >> storage_classes = (UserMessageStorageEngine,) + >> FallbackStorageEngine.storage_classes >> >> (the fallback storage module would have similar issues) >> >> The DB subsystem, which uses backends, is big and has multiple >> classes, so it makes sense for it to be referred to by module names. >> But if there is exactly one class which implements a feature, I don't >> see the sense in having a setting that refers to the containing >> module. There might be a future proofing argument here, but for >> smaller features it sounds like YAGNI to me. >> >> For the cache subsystem, the name of the module (without the 'path') >> is used as the protocol part of a URI-style setting, so it also makes >> sense for it to be short and lower case. >> >> As for the e-mail and session subsystems, IMO they are using the less >> preferable convention. Some of the disadvantages mentioned above don't >> exist for the e-mail backends, because they don't use each other like >> the messages ones do. >> >> Regards, >> >> Luke >> >> -- >> "Idiocy: Never underestimate the power of stupid people in large >> groups." (despair.com) >> >> 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-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. >> >> >> > > > > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > (919) 951-0052 > http://www.caktusgroup.com > -- 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.
