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 -- 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.
