Get Tag Enhancement Proposal: Manager Selection

1 view
Skip to first unread message

Max Cutler

unread,
Apr 28, 2009, 12:14:24 PM4/28/09
to courantnews
So I thought I'd kick off our public design deliberations with an
enhancement proposal for the get tag:

Currently, the get tag will use the default manager on a model, which
is typically the standard Django Manager class to allow for maximal
flexibility on the admin side of things. However, the get tag is
predominately used on the public-facing side of things, where you only
really want to fetch content that has been approved for publication.
For the Article model, we have already created a crude "live" manager
to select only articles with a published status.

Clearly being able to choose which manager to use for fetching content
items is desirable, so the question becomes what the proper syntax
should be. I have some proposals, but am interested in other ideas as
well.

First up, would be using another clause, perhaps called "using". For
example, {% get articles using live manager in section some_section as
article_list %}. I feel like just having "using live" without
"manager" makes it less readable, and makes it clear to other people
what the intention is. So the form "live <manager_name> manager",
where <manager_name> is either the name of the manager on the model or
"default", which would use the model's default manager. If no such
"using" clause is used, then it just uses the default manager by
default.

Another option would be some additional syntax tacked onto the model
specification, such as {% get articles|live ... as article_list %} or
{% get articles.live ... as article_list %}. This is a bit more
concise, but not nearly as readable or immediately understandable
without reading the docs. I'm not sure whether I prefer a pipe (|)
character, which mimics a template filter, or a dot notation, which is
more like what would be used in python code.

A third option would be to specify the filter before the model, like
{% get live articles ... as article_list %} or {% get default
articles ... as article_list %}. While it works well for manager that
are adjectives that make sense as describing that model noun, it
doesn't make as much sense with "default" or other arbitrary names. It
also makes parsing the template tag call a bit more complicated, since
we can't be sure whether the first token after "get" is the model or a
manager (we would have to allow no specification of the manager, in
which case the default manager would be used).

Thoughts? Other possible syntaxes?

Robert Baskin

unread,
May 10, 2009, 12:33:53 AM5/10/09
to courantnews
Here are my thoughts:

The third option will add additional complexity to an already
complicated template tag and parser.

I like the first and the second. I guess I prefer the second, but that
might have to do with my programmer roots. I guess it would be
interesting to get some feedback from somebody with a less technical
background. We assume that an "English" style tag like the first
option is easier, and maybe that's true, but maybe the second option
is just as understandable. Anybody on this list have any opinion on
this? We struggled with the initial implementation of the get tag to
make it as readable and "English" as possible.

As for the Great Pipe vs. Dot Debate of 2009, I prefer dots but could
live with pipes. Pipes look a bit too much like l's (that's a
lowercase L). And it's more Python-esque, which I prefer to Django
template-esque, but see the previous paragraph.

Robert

P.S. I remember when the get tag was just scribbles on a whiteboard.
Memories.

Daniel Bachhuber

unread,
May 10, 2009, 12:52:58 AM5/10/09
to coura...@googlegroups.com
My vote is for the dot syntax. While I understand the assumption that
"English" syntax will be more approachable, I don't think it will be
what people expect. HTML, for instance, isn't an "English" syntax, but
it is something people expect when they're going to be templating
their website. More so, I think that the form needs to be as
straightforward as possible
--
Daniel Bachhuber
www.danielbachhuber.com
danielb...@gmail.com
cell: +1 971 998 5407
aim/skype/twitter: danielbachhuber
Reply all
Reply to author
Forward
0 new messages