The original advice stands - template inclusion tags are just a few
lines of code + the HTML file.
https://docs.djangoproject.com/en/1.3/howto/custom-template-tags/#inclusion-tags
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
{% include "link_to.html" with url="google.com" text="check out google" %}
In link_to.html:
<a href="{{ url }}">{{ text }}</a>
https://docs.djangoproject.com/en/1.3/ref/templates/builtins/#include
as mentioned, django philosophy is against generating code.
--
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/
--
You received this message because you are subscribed to the Google Groups "Django users" group.
I don't normally pass any parameters; you can instead specify that it
should have the template context available to it instead, and then
pull named parameters out of there.
If the parameters that the inclusion template is expecting have
different names to the ones in the context, then I just alias them
using the {% with %} tag.
Cheers
Tom
{% with some_name_my_tag_wants=some_name tag_var2=var2 %}
{% mytag %}
{% endwith %}
NB {% with %} has different syntax in <1.3
Thinking about it, this could be made easier if there was a
standardized wrapper for parsing arguments. Less boilerplate in the
template, less boilerplate in the tag code.
Cheers
Tom
my_tag takes 0 arguments