Great. Here are the tickets: http://code.djangoproject.com/ticket/5971 http://code.djangoproject.com/ticket/5972
And while we're on the subject of tickets: I've been digging around in the jungle of template parsing while working on this patch and and the trans patch, and a thought occured to me. Why can't the Variable class handle processing of filters instead of FilterExpression.resolve? A Variable in a template is either a literal or a variable from the context, and those can in most cases have filters applied to them. Wouldn't it be nice if a Variable would simply have a "filters" list and the resolve method would be the one doing the application of said filters? (with the option to simply NOT apply the filters) Obviously it's a pretty daring idea and I don't have much to back it up right now, but my thought is that there seems to be way too many steps involved in parsing a single token and there are many datatypes; hard to keep track of everything. If we look at it in the scope of tags and {{}} (what would I call that?), then they can basically contain only a few datatypes: literals, context variables, filters and parameters. So why not make it a little more "defined" and give Variables the power they deserve! ;) It's 5am, so my thoughts are not coming out clearly. But if the above makes you think "hmm, interesting", I can write up something more detailed, maybe with some code examples... //Dmitri On Nov 18, 4:08 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2007-11-17 at 18:27 -0800, Dmitri Fedortchenko wrote: > > The django.template.TokenParser has a little problem. > > > I am not sure if this is a problem actually, but it is inconsistent > > when parsing filters that follow constant strings or variables. > > > Meaning that: > > {% tag thevar|filter sometag %} will produce: > > self.value() = "thevar|filter" > > self.tag() = "sometag" > > > However: > > {% tag "a value"|filter sometag %} will produce: > > self.value() = "a value" > > self.tag() = "|filter" > > self.tag() = "sometag" > > > This does not seem like correct behaviour... > > I made a very simple patch for this, thus the outcome of the above: > > > {% tag "a value"|filter sometag %} will produce: > > value = "a value"|filter > > tag = sometag > > I think this is probably the right idea, yes. TokenParser is a bit of an > odd duck. Nothing in core uses it except the i18n template tags, so it > hasn't gotten as much attention during the recent Variable refactoring. > When I do work in the i18n template tags I realise that the API of > TokenParser really isn't particularly handy (it kind of cries out for an > iterator, for example). Fortunately, most changes can be made > incrementally and without backwards incompatibilities. > > I've kind of been holding off on doing much work here since it currently > "mostly works" and Tom Tobin had some good ideas about making template > tag creation a bit easier. I've been hoping to work with him at some > point to get that polished up and into trunk. One of the places it would > help simplify is django.templatetags.i18n. > > For now, I'd be happy if you'd create a ticket with your patch to make > the above change. It's slightly backwards incompatible, but not in a > hard-to-fix way for downstream developers (normally, the result of any > such expression is going to be passed to compile_filter() anyway and > this makes that easier). > > Regards, > Malcolm > > -- > Remember that you are unique. Just like everyone > else.http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---