Update: NEW PROPOSAL.
After extending and refactoring template.Library, and using block_tag as
described above for almost all the built-in tags, I came to the conclusion
that we can improve the template tag definitions even more. I would
introduce some thing as class based template tags.
Actually, all of the template tags return a Node instance after parsing.
And almost all the template tag that we have, can be expressed as a grammar
like this: 'if elif* else? endif'. (Exceptions are comment and verbatim,
which ignore the inner template tags, and trans/blocktrans which have some
backward compatibility code in there.)
There is no reason for not adding some abstraction level to the parser, as
long as it's well implemented. The node tree, after parsing will be exactly
the same. It's just the compile-functions which can be abstracted.
I propose creating a class TemplateTag, which inherits simply from Node.
Actually, it's a node that was created because the template tag was found
in the template. TemplateTag.__init__ will receive the parts, like for
instance:
class IfTemplateTag(TemplateTag):
grammar = 'if elif* else? endif'
def __init__(self, parser, parts):
self.conditions_nodelist = []
for p in parts:
if p.name in ('if', 'elif'):
condition = TemplateIfParser(parser, p.args).parse()
self.conditions_nodelist.append( (condition, p.nodelist) )
elif p.name == 'else':
self.conditions_nodelist.append( (None, p.nodelist) )
library.register(IfTemplateTag)
(Probably, I'll make it TemplateTag.parse, instead of __init__, so that we
can save the nodelists to the class and make the nodelists property
automatically.)
Register would call IfTemplateTag.create_compile_func(), and add it to
library.tags, and this compile function will have a pointer to the Grammar
and TemplateTag class for introspection.
It's powerful. The "with"-template tag, will probably be not much more than
adding a ContextMixin to the TemplateTag.
If no-one is against, I go on improving and implementing this. I strongly
believe that there's a lot of room for improvement here, without loosing
backwards compatibility or performance.
QUESTION: Do we consider the classes IfNode, IfEqualNode, etc... part of
the public API? They don't appear anywhere in the documentation.
It is because if I implement the new template tag definitions, I'l like to
refactor all the built-in template tags to use the new style. (As using
more of Django -- inside Django.)
And this can probably break some monkey-patches on django for those who do
it.
Cheers,
Jonathan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
