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.
