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. 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. 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 %}. 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.
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 %}
for a - in my opinion - pretty common usecase and good design practice
(modularization).
OK, the "long line" argument and short tags are a point, but I still
see the maintenance of multiple nested levels of {% with %} context as
much more problematic.
Well, anyway, thanks for clarification, if anyone thinks I should
carry this to the developer's list or trac let me know, otherwise I
will just stick with what we've got.
Regards,
Flo
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
