On Sat, 2007-11-17 at 19:55 -0800, Dmitri Fedortchenko wrote:
> 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?
Because Variable was introduced only very recently and
FilterExpression.resolve() has been there since about day one. The
incremental changes haven't got that far.
> 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)
It's that last point that points to why the current design might have
some benefits. At times we need to differentiate between the variable's
value itself and the variable after all filters have been applied.
There's still a possibility of folding things in together, but the
current version is completely silly either. It's mostly just a naming
issue (do you call the method on this object or that object?) ,though.
The functionality isn't likely to change too much.
> 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! ;)
I suspect you're really just talking about folding FilterExpression into
Variable, for the most part. Might be worth it eventually. The nice
thing is that this sort of stuff can all be done incrementally and
without too much external disruption. We don't want to go nuts and break
everybody's code needlessly, so any changes *must* bring very real
benefits and not just count as rearranging the deck chairs to make them
look nicer, because that's asking external filter writers to make
changes for no actual benefit.
Still, I agree with your thinking in general. Some of those internals
could do with a broader look now that we've got a couple years more
experience in how things are being used. We could encourage wider use of
TokenParser (and document it). We can incorporate Tom Tobin's ideas for
making it easier to write template tags. We can possibly tidy up some of
the internal interfaces (as you've no doubt seen,
django.templatetags.i18n does a lot of duplicate work that smells a bit
unnecessary and that's for historical reasons: more helper code has been
added since it was first written).
By all means, dive in and try some things out. Be very aware of
backwards compatibility. Or, rather, then pain inflicted when you break
it, so have a really good reason if you must do so. Try to work in
smallish incremental stages, as much as possible, so that our heads
don't explode when we try to review the patches.
Regards,
Malcolm
--
No one is listening until you make a mistake.
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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
