On Tue, 2008-09-16 at 20:36 +0200, Johannes Dollinger wrote: > Why should django.template be refactored? Filter and Variable parsing > is inconsistent. Many ad hoc parsers in defaulttags are fragile. > Whitespace handling is ungraceful. > > The patch provided in #7806[1] splits __init__.py into separate > modules[2] and introduces a TokenStream class that allows parsing of > literals, vars (called lookups) and filter expressions.
As was pointed out the first time you brought this up, keep in mind that there still need to be ways to manually control the lexing phase. Not every template tag has the same requirements there. Also, since the Variable class is part of the public API (we document how to write custom template tags), you need to preserve backwards compatibility. For example, anything written according to custom-template-tags.txt should continue to work unchanged. There are possibly some reasonable other methods in template/__init__.py that should continue to remain available as well. That being said, I'm completely in favour of a bit of shuffling in those files to make things easier to understand and fix a bunch of little inconsistencies. However, I'd encourage doing it in slightly smaller steps than the original patches I read so that we can see that backwards compatibility is maintained and do the smallest number of changes necessary to tidy things up. Basically, keep the refactoring and the feature/API addition portions distinct. For example, it's useful (and necessary) to make the Variable class be a lot more consistent with respect to also resolving the effect of apply filters to variables (right now, anything using Variable doesn't have filter effects applied, which was probably just an oversight originally). Helper methods that make it easy for the common cases to say "I expect three paramters matching the 'x y as z' pattern where x and z are strings and y must be an integer" would be very handy. This is where method like your parse_int and parse_string methods are additions that would be useful. Things like parse_expression is probably overkill for a high-level API, since resolving the effect of filters should really just be a natural part of Variable.resolve_context(). I'm not sure I see the use-case at the moment for parse_expression; perhaps you could elaborate with an example. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
