Not sure if this is still an ongoing discussion, but I prefer to write
all new tags with a simple syntax that matches Python. There's no
real advantage in defining a unique, custom syntax for a template
tag.
All HTML authors are already familiar with Python's kwargs syntax,
since it exactly matches how HTML tags and attributes themselves
work. There's no great leap of difficulty going from:
<div class="something" style="something">
to
{% tag foo="something" bar="something" %}
Allowing for arbitrary custom syntax makes tags harder for HTML
coders, since they have to remember these special custom syntaxes
which they're not used to.
On Sep 12, 7:51 am, Donald Stufft <[email protected]> wrote:
> 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
> > athttp://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.
