On Sep 14, 9:31 am, "Jonathan Buchanan" <[EMAIL PROTECTED]>
wrote:
>
> Template tags really are the best place to put display-specific logic
> like this. The original problem specified (a custom button and
> associated JavaScript for an object with the object's name in the
> button's id) could be solved using a template filter:
>
> BUTTON_TEMPLATE = u"""<span id="%(type)sButton-%(id)s"></span>
> <script type="text/javascript">
> Button.create("%(type)sButton-%(id)s", "%(text)s");
> </script>"""
>
> def button(obj, text):
> """
> Usage::
>
> {{ some_object|button:"Choose me!" }}
> """
> return BUTTON_TEMPLATE % {
> 'type': obj._meta.object_name.lower(),
> 'id': obj._get_pk_val(),
> 'text': ugettext(text),
> }
> button = register.filter(button)
>
> If you wanted to have the button rendered from a template file, that
> would be easy to add. Or if you wanted a different template file to be
> used depending on the type of object (say, with each specialised
> template inheriting from a generic button template), that would also
> be pretty easy.
>
Jonathan,
Thanks for the response. But to be fair to you I must disclose that I
anticipated that someone would present this as an answer. I would have
added this discussion into the original but it was already a bit
long... :-)
Here's the issue: while your solution works in this instance, it is
not a general solution to the problem.
So I have my Button template tag, and it allows both a type (or
discriminator, as I've been thinking of it) and an id, and it
arbitrarily mashes them together. So far, so good.
What if the next instance of a button needs an id that looks like
this?
parrotButton-{{ parrot.flock.id }}-{{ parrot.id }}
Or what if the text for the button is this?
Choose {{ parrot.name }}!
As you can see, the template tag code can quickly get arbitrarily
difficult and convoluted. Basically your solution requires that the
Button tag code anticipates every use to which it will ever be placed,
and this is one of the problems with this approach to which I object.
While you will always be able to present a specific solution to a
specific instance, your solution does not cover the general case which
leads to truly reusable template tag code.
Additionally, if we truly wish to allow the coding of templates by
people who are good at HTML, and leave the Python coding to the people
who are in turn good at Python, this sort of solultion requires the
template programmer to know Python in order to create tags that
reflect his or her needs. This is of course one of my main objections
to this approach: removing expressions from the template language
actually sabotages the main goal of separation of presentation and
logic.
> For the other options you went on to mention (including extra,
> optional arguments), a "full" template tag would probably be in order.
> You wouldn't have to place all the necessary data in the context first
> as you stated - e.g. if you wanted to be able to specify a class for
> the button, it wouldn't be too much work to implement a tag which can
> sort this out:
>
> {% button some_object "Choose me!" class=superButton %}
This solution generalizes to the case I mentioned in which the
template tags are responsible for parsing the expression language.
While it's possible to do this (and indeed I pointed this out in my
original post), it requires the template tag to be responsible for
anticipating how the tag will be used. While it is no doubt an
improvement, in the end the elegant solution is to allow the template
to responsible for this parsing so that even tags which do not
incorporate this special functionality can be used with expressions.
Now when I say expressions, I believe that at least 80% (if not more)
of my objections could be addressed by allowing the following sort
construct in template tags only:
{% mytag "${some.context.variable}-arbitrary-${other.variable}-text"
"Choose ${ parrot.name }!" %}
There... no dirty logic, no arithmetic, nothing really objectionable
as far as I can see with regards to the stated philosophy, but it
opens up a whole world of possibilities for the template designer that
are currently rather difficult and unnecessarily time-consuming to
accomplish. One could even place this in the split_contents function
to get halfway there, but I still believe it is most useful when
implemented by the template parsing system. I mean, even Velocity
allows this, and they're a good deal more dogmatic about it than the
Django folks seem to be.
> Jonathan.
Again, thank you for the response, and regards,
-scott anderson
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
