On Thu, 2009-04-30 at 12:22 -0700, Julián C. Pérez wrote:
> jajaja i know
> that what just a stupid example to make my point...

Well, the details are important for something like this, since the
complexity of what you're after dictates which solution approach might
be most appropriate.

> i plan to make more complex custom tags

A template tag has no way of knowing what is intended to be literal and
what you want to replace with dynamic content, by default. All the
arguments are simply passed in as a big string to the template tag. So
if you want to treat something as a variable, it's up to you to work out
which parts are the variable parts and look them up (via a resolve()
call) appropriately in your template tag class's render() method.

You might want to consider if using Django's variable substitution
syntax is really what you want to use there, as it's likely to lead to
confusion (because normally that syntax is not appropriate inside
template tags). Also, consider if a template tag that takes all that
information as an argument is the right approach (which is what you're
doing now), or if it might be better to use a block tag of some kind.
For example, Django's localisation support needs to able to replace
content with variables in places, so it uses a block tag structure:

        {% blocktrans foo|bar as baz %}
        Here is some content containing {{ baz }}.
        {% endblocktrans %}
        
You could have a look at the blocktrans tag for some sample
implementation code.

In short, though, you -- as the template tag author -- have to
explicitly write your tag argument processing to understand the context
in which the arguments should be treated, whether as literals or
variables or function calls or... . There's no default syntax for
variables in template tags, because the possibilities are a bit too
broad (and, ideally, a template tag is still relatively simple and won't
need complex variable substitution like that).

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to