Hi all,
> For many years, writing templatetags has been among the most hilariously
> complicated things we Django developers did. Anyone who has written parsing
> for
> templatetags, over and over, shares this pain. Further, the current syntax
> present a tremendous problem for Armin Ronacher's GSOC towards template
> compilation: template tags define a ``render()`` method, which takes the
> current context (a stack of dictionaries) and perform some behavior which is
> opaque to the caller. This is a problem because one of the core objectives of
> the template compilation infrastructure is to store the template context in
> Python local variables, rather than in dictionaries. For all these reasons,
> several of us (myself, Idan, Russ, Carl Meyer, Andrew Godwin, Jonas Obrist,
> Chris Beaven) just sat down (we actually stood, mostly) and tried to iron out
> a
> proposal that solves these problems, taking inspiration from the plethora of
> libraries that exist today.
>
> We ultimately created two possible solutions, one inspired primarily by
> django-classy-tags and django-templatetag-sugar, the other mostly inspired by
> django-ttags.
FTR, the app is called django-ttag, not django-ttags.
> We came to a fragile agreement on the first. We primarily
> evaluated two cases for these, one very simple, the other more complex, and
> compared the resulting implementations.
>
> The first case we considered was a templatetag which takes two, required,
> arguments. Invocation looks like ``{% mytag foo bar %}``. The two definitions
> look like:
>
> class MyTag(Tag):
> args = [
> Argument("foo"),
> Argument("bar"),
> ]
>
>
> class MyTag(Tag):
> foo = Argument()
> bar = Argument()
>
>
> the second case we considered was a tag which has one required, positional,
> argument, and two optional, keyword arguments, which can occur in any order,
> followed by a final, optional keyword argument, meaning any of the following
> invocations are valid:
>
> {% mytag src limit 1 offset 10 %}
> {% mytag src limit 1 offset 10 with foo %}
> {% mytag src limit 1 %}
> {% mytag src offset 10 limit 1 %}
> {% mytag src %}
>
> and the two implementations were:
>
> class MyTag(Tag):
> args = [
> Argument("source"),
> Unordered(
> NamedArgument("limit", required=False),
> NamedArgument("offset", required=False),
> ),
> NamedArgument("as", required=False, resolve=False)
> ]
>
>
> class MyTag(Tag):
> source = Argument()
> limit = NamedArgument(required=False)
> offset = NamedArgument(required=False)
> as_ = BasicArgument(required=False)
>
> class Meta:
> ordering = (
> ('source',),
> Unordered('limit', 'offset'),
> ('as_',)
> )
>
> The general consensus was that the second implementation was *very* slightly
> preferable in the simple case, however it was significantly more complicated
> in
> the second case, and thus the first implementation was preferable overall.
I'd like to express my sincere discomfort with the two example cases you used
to develop the API. At least from the experience I have with writing template
tags (with the standard API, @simple_tag, django-template-sugar,
django-classy-tags and django-tagcon/ttag) it was the simple use cases that
were more common, rather than the complex in day-to-day work. While one could
say that this has something to do with my coding style and clients, I'd have
to say that keeping the template tag API simple instead of complex has always
been a major goal. So unless there was a decision to start encouraging moving
business logic from the views to template tags (which would be indicated by
increased complexity) I don't see a reason to prefer the API that allows
complex API.
As a matter of remote contribution to the discussion at the sprint, I've just
checked if django-ttag (the example which you preferred for the simple case)
is capable of passing your complex case, too (yes):
https://github.com/jezdez/django-ttag/compare/django-tag-api
I'm happy that there was some discussion at the conference sprint though,
since it's an important topic, but I'd appreciate if you'd provide further
explanation of why you prefer the first, django-classy-tag and
django-template-sugar influenced example.
Since I've also worked on django-ttag (including when it was still called
django-tagcon a long time ago) quite a bit, I assume you mostly discussed how
to handle ordering the different kinds of arguments (positional vs. keyword
vs. "named" arguments). Luckily we already have a pretty strong convention for
that, as you can see when specifying forms or models. Which is why I'm
confused why an "args" class attribute would be needed in your preferred
example.
Any elaboration as to why this verbose syntax is needed would be appreciated.
Jannis
--
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.
