On Sat, Dec 5, 2009 at 8:40 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > * Why have all the tests migrated to the Django system tests? This is > a contrib app - the tests should be internal to the app.
They were moved to facilitate inclusion of a more complete test suite with a test urls.py and views.py that make sure all the plumbing works together. In short, I wanted a way to make use of the test Client without including the dummy code in the distribution. I think it has also been discussed elsewhere; that some would prefer not to deploy the tests with the production application - one more reason to keep them in 'tests' instead of in the contrib app. >From what I can tell, this seems to be in line with what some of the other contrib apps are doing, such as admin and comments. > * 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. Sounds good - changed. > * 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.LegacyFallbackStorage' Really? Files definitely seem to be more on the "storage" side of things: http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py > * The cookie backend is still doing a conditional import for json. The > django.utils.simplejson module already does this conditional import > check. Whoops, thanks. Removed it for real this time. :) > The rest of my notes are minor documentation fixes: > > * The documentation for the message settings that modify old settings > (MIDDLEWARE_CLASSES, TEMPLATE_CONTEXT_PROCESSORS) should have a > ..versionchanged note to indicate that they have changed in 1.2. This > has been done in the template API docs, but not in settings.txt. Added. Also added a ..versionadded in the middleware ref. > * The deprecation note in topics/auth.txt says the new messages > framework should be used "whenever possible". This makes it sound > optional, when it isn't. Updated, thanks. > * The explanatory note in "Configuring the message engine" in the > message docs isn't required - or at least, isn't required until > *after* you have described the fact that storage backends are > configurable. Removed. > * The markup for the note about using standard message levels in > reusable apps should be marked up using ..note:: syntax, so it is > rendered as a breakout box. Fixed, thanks. > * The explanatory note about overriding MESSAGE_LEVEL should be marked > up as an ..admonition:: , and should probably have an example to show > the correct technique. Good call, added, thanks. Other than the question about renaming storage -> backend I think we are close to prime time. Let me know what you think. Cheers, Tobias -- 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.
