I'll +1 the restriction of template tags to being arg/kwarg like. I see no
reason, other then porting already written tags, to worry about the ability to
do ``{% mytag foo as bar %}``. Personally I would think it would be desirable
to make this match python as much as possible. Python programmers will find it
more familiar then attempting to turn parameter passing into a parsing
situation, and non python programmers will find it simple enough learn quickly.
Being a restricted grammar, it also has the benefit to have less surprises, you
don't have to worry about how this random tag works, there's one (obvious) way
of doing it.
Something like
class MyTag(tags.Tag):
width = tag.IntegerArgument()
height = tag.IntegerArgument()
using = tag.StringArgument(required=False)
as = tag.StringArgument(required=False, default=None)
which would translate to:
``{% mytag 600 700 %}``
``{% mytag 600 700 as="mytag_return" %}``
``{% mytag 600 700 "template_name.html" %}``
``{% mytag 600 600 using="template_name.html" as="mytag_return" %}``
The only thing I really don't like about this is the ``as`` kwarg. We could
stuff a boolean into a Meta class that is something like ``allow_assignment``
which will support something more like what we have now…
``{% mytag 600 700 as "mytag_return" %}``
``{% mytag 600 700 "template_name.html" as "mytag_return" %}``
``{% mytag 600 700 using="template_name.html" as "mytag_return" %}``
With the stipulation that the as [keyword] must appear as the last item in the
tag.
On Monday, September 12, 2011 at 7:17 AM, Jannis Leidel wrote:
> 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]
> (mailto:[email protected]).
> To unsubscribe from this group, send email to
> [email protected]
> (mailto:[email protected]).
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
--
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.
