On Thu, Nov 5, 2009 at 9:15 AM, Russell Keith-Magee <freakboy3...@gmail.com>wrote:
> * In the discussion about message levels mentions tags before tags > have been introduced. The section on levels should introduce the > messaging levels without reference to the tagging process. > Fixed. > * The explanation of tags says they are a 'string representation', > but doesn't clarify what that string is useful for. Is it a verbose, > human readable name? An identifier? A name suitable for a CSS class? > Added. > * There also seems to be a lot of attention paid to the numerical > values for constants. Ordinarily, you don't really care about the > numerical values of system constants - you just use them. To my mind, > the numerical values of the constants are irrelevant until you get to > the 'custom level' section - where they are only relevant because you > need to know the numbers you can't use. > Moved listing of values to the custom level section and added descriptions of levels in the original spot. > * The example custom level CRITICAL doesn't have a consistent value - > it's 50 in places, 60 in others. > Whoops, thanks for catching. > * The explanation around minimum recorded message levels could do > with some elaboration. It isn't entirely clear to me what the > message.level setting does - is it a minimum level? maximum level? > inclusive or exclusive? The example here needs to be richer - showing > an example of a message that _won't_ be stored, for example. > Good call. Added. > * Similarly for extra tags - are the extra tags concatenated onto > message.tags? Are spaces added? will message.tags become a list? > I think it basically said that already but I tried to clarify what was there, and added some explanation about how tags are stored, in general, in the first section on tags. I'd be open to the argument that tags should be stored in a list instead of a string, in case you want to do other things with them and/or space delineation doesn't work for you. * The description of LegacyFallbackStorage storage could do with some > elaboration. I'd almost go so far as to say that there should be a > whole section in the docs about this storage backend, and exactly how > it operates - the original list where the storage engines are > introduced should provide a link to a more detailed section. Questions > that need to be addressed: > > * In what order are messages retrieved from cookie,session and database? > * Do I need to do anything to my existing user.message_set code? > * What level do old-style messages get? > Added. * Following the lead of contrib.comments, you may want to consider > splitting the settings documentation into a separate documentation > module. > Seems silly for just 3 settings, especially since the settings are already documented on a separate page (the full list of settings), but it looks like that's all comments has too. So, if it's the new convention and other apps are doing the same, I'll split it up. > On a code level - I noticed that the messages middleware is in the > list of defaults in the settings.py template, but not in > global_settings.py. A minor inconsistency, but one I noticed while > trying to work out exactly what the transition requirements would be > for existing projects. > Whoops, thanks for catching that. Added. > I had a quick poke around the rest of the code base, especially about > transition issues. However, I didn't want to start in on a big > teardown unless you thought the code was ready for it. When you're > ready for a the full latex-glove treatment, let me know. :-) > Will do. I have a little cleanup to do regarding EOFMessage per some feedback from Luke Plant but I think it should be ready soon. Thanks for all your feedback thus far! 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=.
