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
-~----------~----~----~----~------~----~------~--~---
