On Wed, 2009-01-21 at 00:40 -0800, Flo Ledermann wrote:
>
>
> On Jan 21, 12:06 am, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
> > Huh? You have some change you want to make to the way a template tag
> > behaves, but you don't want to write a custom template tag to do that?
> > That doesn't sound very logical. If you want template tag behaviour, use
> > a template tag.
>
> No, no, that's not what I meant. My suggestion was that django users
> in general should not need to write a custom template tag for getting
> support for parametrizeable includes in a concise form.
That's reasonable. The solution isn't "introduce a new tag", however.
It's "don't do that." :-)
> Obviously, if
> the functionality isn't there now, someone has to write such a
> template tag or extend the existing one, but in my opinion this is
> something that would be justified to go into the core for subsequent
> "out-of-the-box" use by others.
>
> It seems to me that parametrization in general is something that is
> considered to be beyond the scope of template authors in Django's view
> of the world.
Precisely.
> You can call a method on an object (through the template
> system's lookup mechanism), but you can't pass parameters to that
> method. You can include another template, but you can't pass
> parameters to it (using a single construct). Since I believe to have
> found a general pattern here, I can digest and accept it as a general
> design decision, though I find it a bit curious sometimes. What
> happens is that these things are transferred to the *context*, either
> by populating the template's data dictionary with values pre-
> calculated in the view, or by using {% with .. as %}.
Preferably the former. "with" is a bit of a wart that is necessary for a
couple of limited cases, but can be over-used.
> Why putting
> things in the context is inherently better than allowing
> parametrization (for "non-programmers" or whoever the target users for
> template authoring are) in all cases is just not clear to me.
Think of template rendering as handing the template a bag of data and
the template renderer removes pieces and slots them into place. Trying
to rename variables and do the equivalent of function calls with
parameters is crossing the line from "filling in the slots" tp
"programming in templates". And the original template design, with which
newer maintainers, such as myself have agreed is quite a good idea, is
to encourage any such complex algorithmics to be done at the Python
level. Sure, the line between presentation and programming is a little
fuzzy in places, and there are some things that are in which could be
out and some things that might be in and aren't. In general, though,
we're pretty consistent in discouraging anything that looks like
programming in templates. Your (Python) views construct the data you
want in the right format and then the template authors only have to slot
them into place.
>
> Coming back from the generalization to my usecase, i cannot see how
>
> {% with a as b %}
> {% with x as y %}
> {% include "foo.html" %}
> {% endwith %}
> {% endwith %}
>
> is syntactically or semantically superior to
>
> {% include "foo.html" with a as b, x as y %}
Because, no code will ever be that short. People don't use one-letter
variable names for a start (those that do should stop). People won't
restrict themselves to just one or two aliases if that becomes a
recommended usage pattern (have a look at the argument lists to
functions some time). Your example is artificially simple. In the cases
where you only need to do one or two things, the above is fine; it's not
overly long if you really need it in one or two or five places. If
you're doing it regularly, either come up with an approach that doesn't
treat inclusions like function calls, or write a custom template tag
(once!) that allows you to use whatever pattern you like.
We're not discouraging modular coding. Far from it. We're simply saying
that there aren't template-level namespaces (which is all that variable
aliasing is in programming languages). If you're going to substitute
things into template foo.html, use the same names all the time. Use
common, descriptive names in foo.html and the views that include that
data won't be unclear. There are enough descriptive words in the English
language (or language of choice) that avoiding name collision just isn't
that hard.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
