Re: Arithmetic operations in a templete
On Sep 14, 12:46 pm, "Jonathan Buchanan" <[EMAIL PROTECTED]> wrote: > I'd have to take a look at how that tag was implemented, but I'd > likely start out with something horrific, like the attached patch :D Tsk, tsk. Bending the rules of the game a bit now, aren't we? :-) Again, yes, you could do all of that. I'd rather not have to patch/ decorate/modify existing Django code for a specific application to do it, however. Regards, -scott --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
On 9/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On Sep 14, 11:29 am, "Jonathan Buchanan" <[EMAIL PROTECTED]>
> wrote:
> > Pesky kids these days, with your music and your anticipation...
>
> :-)
>
> > I agree that what you propose here would be useful in the scenario
> > you've described. *Personally*, if I wanted something like that, I'd
> > just write a function to do it and use it on my tag arguments.
> >
> > Quick and dirty implementation (assuming the template library will
> > allow you to pass your example tag arguments as-is):
> >
> > expression_re = re.compile(r'\$\{ *([a-z0-9\._]+) *\}')
> > expression_re.sub(resolve_variable(r'\1'), your_tag_argument)
>
> But if you wanted to use that logic in a tag defined by someone else,
> say, the url tag...
>
> Regards,
> -scott
I'd have to take a look at how that tag was implemented, but I'd
likely start out with something horrific, like the attached patch :D
Jonathan.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
template-expressions.diff
Description: Binary data
Re: Arithmetic operations in a templete
On Sep 14, 11:29 am, "Jonathan Buchanan" <[EMAIL PROTECTED]>
wrote:
> Pesky kids these days, with your music and your anticipation...
:-)
> I agree that what you propose here would be useful in the scenario
> you've described. *Personally*, if I wanted something like that, I'd
> just write a function to do it and use it on my tag arguments.
>
> Quick and dirty implementation (assuming the template library will
> allow you to pass your example tag arguments as-is):
>
> expression_re = re.compile(r'\$\{ *([a-z0-9\._]+) *\}')
> expression_re.sub(resolve_variable(r'\1'), your_tag_argument)
But if you wanted to use that logic in a tag defined by someone else,
say, the url tag...
Regards,
-scott
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
> 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... :-)
Pesky kids these days, with your music and your anticipation...
> 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.
I agree that what you propose here would be useful in the scenario
you've described. *Personally*, if I wanted something like that, I'd
just write a function to do it and use it on my tag arguments.
Quick and dirty implementation (assuming the template library will
allow you to pass your example tag arguments as-is):
expression_re = re.compile(r'\$\{ *([a-z0-9\._]+) *\}')
expression_re.sub(resolve_variable(r'\1'), your_tag_argument)
> Again, thank you for the response, and regards,
> -scott anderson
Thanks for the interesting discussion, I only wish I had time to
participate in it properly. 5pm approaches :)
Jonathan.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
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"""
>
> Button.create("%(type)sButton-%(id)s", "%(text)s");
> """
>
> 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
Re: Arithmetic operations in a templete
> However, simply dodging the question doesn't address the original point:
> why does Django adhere to such a nannyish philosophy, and how do you
> solve the problem I presented *within Django* in a reasonable way?
>
> Thanks and regards,
> -scott anderson
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"""
Button.create("%(type)sButton-%(id)s", "%(text)s");
"""
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.
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 %}
Jonathan.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
Yes, that's always the fall back, isn't it? I'll look at Jinja, as I didn't realize there was such a fork. Apparently I'm not the only one who thinks this way. I'm concerned with how well a solution like this tracks the Django release. However, simply dodging the question doesn't address the original point: why does Django adhere to such a nannyish philosophy, and how do you solve the problem I presented *within Django* in a reasonable way? Thanks and regards, -scott anderson On Thu, 2007-09-13 at 23:46 -0500, James Bennett wrote: > On 9/13/07, Scott Anderson <[EMAIL PROTECTED]> wrote: > > What I'm hoping, however, is that this missive was moot, because you'll > > say, "no, Scott, you should just do *this*:", followed by an elegant and > > reasonable solution that I, as a relative newcomer to Django, have not > > yet considered. Here's to your reply, and cheers! > > OK, here you go: > > Use another template system, either site-wide or for the cases where > the Django template system isn't doing what you need. It's not hard to > do this, and it opens up the possibility of using any or all of the > vast number of Python template systems available. > > The Django template system, at this point, will almost certainly > *never* include the type of functionality you're asking for, so use > another template system that does or that's more willing to bend its > philosophy to suit what you want. If you like the rest of the Django > template system I'd suggest you try Jinja, which started as a fork of > Django's template system and so is nearly feature-for-feature > identical, but adds arbitrary Python expressions. > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
Thank you, but that's exactly what I said I *didn't* want to do, because it's silly. :-) Why should my *data model* know *anything* about the presentation? And what happens when I want a parrot row ID, or a parrot foo ID, or a parrot cheese ID? Suddenly I have a proliferation of things in my data model that have jack all to do with the data, and everything to do with a particular implementation of a particular view. And then don't forget the Sloth Button ID as well... so if I have two different data objects with similar presentation needs (but no other similarities beyond that), I have to either a) introduce an inheritance dependency that really makes no sense or b) duplicate a lot of code. And then there's the fact that I can't use my nice generic button tag with anything other than data that understands how it's supposed to be displayed by a particular tag. Regards, -scott anderson On Fri, 2007-09-14 at 09:14 +, Samuel Adam wrote: > no, Scott, you should just do *this*: > > In your Parrot model, you could add a property that displays your DOM > id. > > class Parrot(models.Model): > # fields > > def _domid(self): > return ''parrotButton-%s" % self.id > domid = property(_domid) > > and use parrot.domid in your templates. > > On 14 sep, 06:46, "James Bennett" <[EMAIL PROTECTED]> wrote: > > On 9/13/07, Scott Anderson <[EMAIL PROTECTED]> wrote: > > > > > What I'm hoping, however, is that this missive was moot, because you'll > > > say, "no, Scott, you should just do *this*:", followed by an elegant and > > > reasonable solution that I, as a relative newcomer to Django, have not > > > yet considered. Here's to your reply, and cheers! > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
no, Scott, you should just do *this*: In your Parrot model, you could add a property that displays your DOM id. class Parrot(models.Model): # fields def _domid(self): return ''parrotButton-%s" % self.id domid = property(_domid) and use parrot.domid in your templates. On 14 sep, 06:46, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 9/13/07, Scott Anderson <[EMAIL PROTECTED]> wrote: > > > What I'm hoping, however, is that this missive was moot, because you'll > > say, "no, Scott, you should just do *this*:", followed by an elegant and > > reasonable solution that I, as a relative newcomer to Django, have not > > yet considered. Here's to your reply, and cheers! > > OK, here you go: > > Use another template system, either site-wide or for the cases where > the Django template system isn't doing what you need. It's not hard to > do this, and it opens up the possibility of using any or all of the > vast number of Python template systems available. > > The Django template system, at this point, will almost certainly > *never* include the type of functionality you're asking for, so use > another template system that does or that's more willing to bend its > philosophy to suit what you want. If you like the rest of the Django > template system I'd suggest you try Jinja, which started as a fork of > Django's template system and so is nearly feature-for-feature > identical, but adds arbitrary Python expressions. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
On 9/13/07, Scott Anderson <[EMAIL PROTECTED]> wrote: > What I'm hoping, however, is that this missive was moot, because you'll > say, "no, Scott, you should just do *this*:", followed by an elegant and > reasonable solution that I, as a relative newcomer to Django, have not > yet considered. Here's to your reply, and cheers! OK, here you go: Use another template system, either site-wide or for the cases where the Django template system isn't doing what you need. It's not hard to do this, and it opens up the possibility of using any or all of the vast number of Python template systems available. The Django template system, at this point, will almost certainly *never* include the type of functionality you're asking for, so use another template system that does or that's more willing to bend its philosophy to suit what you want. If you like the rest of the Django template system I'd suggest you try Jinja, which started as a fork of Django's template system and so is nearly feature-for-feature identical, but adds arbitrary Python expressions. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
On Thu, 2007-08-23 at 21:59 +0800, Russell Keith-Magee wrote:
[...]
> Generally speaking - you don't.
>
> This is by design. Django tries very hard to prevent you from putting
> logic into a template. Logic and calculations belong in the view; the
> template shouldn't have any need for calculations. If you maintain
> this strict separation, it becomes possible to change the template
> without altering the view, and vice versa.
>
> To this end, the Django template language is not, nor will ever be a
> Turing complete programming language. We have specifically avoided
> adding arithmetic operations, etc.
> There are a few very basic math filters - but they exist only to
> support display-based calculations. How many pixels wide does this DIV
> need to be, given the size of its component parts - that sort of
> thing.
>
> If you think you need to do arithmetic in a template - think really
> hard about what you are doing. Are you actually trying to change a
> display feature, or are you changing the information that is being
> displayed? If it is the latter, the calculation should be in the view.
Hello,
Interestingly (to me, at least), I'm having issues with this very design
decision right now. Please bear with me, because this is a rather long
response.
While in general I agree with the whole "logic in views and display in
templates" idea, there are some very practical situations in which this
simply becomes a pedantic pain. And while in general Django is a very
nicely practical (yet still elegant) framework, I have to say I dislike
this approach quite a bit.
Here's why:
Let's say I have a set of objects, let's call them Parrots. Each Parrot
has an id, natch.
Now in my template, I'm building a list of these Parrots, and each row
in the list has a button that selects that Parrot when clicked. In
general, in the Javascript and HTML, this looks like this:
Button.create = function(id, label) {
some script to turn that DOM element into a DHTML button
}
Button.create('parrotButton-1', 'Choose me!');
Hi, I'm the Parrot named Moe, and I'm #1!
Button.create('parrotButton-2', 'Choose me!');
Hi, I'm the Parrot named Schmoe, and I'm #2!
And so on.
The template might look like this:
{% for parrot in parrots %}
Button.create('parrotButton-2',{% trans 'Choose me!')
Hi, I'm the Parrot named {{parrot.name}}, and I'm #{{ parrot.id }}!
{% endfor %}
All well and good. But now let's say I'm an appropriately (read:
responsibly) lazy programmer, and I wish to make a template tag that
outputs button code with a particular ID.
Easy, you say! {% myButton theId, 'Choose me!' %}, with the appropriate
Python code (and parsers, and so on) behind it.
As far as "Choose me!" goes, I can do the ugettext translation in the
tag, of course. However... the obvious problem becomes this: how do I
get "parrotButton-1" into theId? I don't want to hardcode
"parrotButton-" in the Python code, because when I have a list of tree
sloths on the same page, that won't make much sense (nor will it work if
we have both Parrot #1 and Sloth #1 on the same page).
I could write (or find) a tag that concatenates two strings, and places
the result in the context:
{% cat currentId "parrotButton-" parrot.id %}
{% myButton currentId %}
But what happens when I add other spanky new parameters to my button
tag, like "buttonText" and "buttonClass" and so on? Now I have to first
run a bunch of (possibly) specialized tags to put the values in the
context, and then call the myButton tag.
This reminds me horribly of the Bad Old Days of JSP, which I am
desperately trying to forget.
Ah, you say, but you're doing this wrong! Put this into your view code!
And here (finally) we get to my response to this thread: why on earth
would I put *template specific* code into my view? Now, instead of
having only some Javascript and a template that knows how to manipulate
it by creating the appropriate HTML, I have some Javascript, a template,
and a view that all have to know that the Javascript wants
"parrotButton-" + parrot.id... not only is this a pain, but it's a bad
idea. DRY and all that. Not only not only that, but I also have to
iterate my Parrots twice: once to set a bunch of constructed button IDs
somewhere, and once in the template to print them all out.
However, I don't *want* code in my view that knows about what my
Javascript and my HTML are doing in the first place. The string
"parrotButton-" + parrot.id has absolutely nothing to do with the data.
The view should keep its hands out of this. This is not logic, it's not
a calculation other than in the most remotest sense, and I'd really,
really like to keep this particular construction as close to where it is
used as possible. I also don't want a function on the Parrot itself that
knows to create "parrotButton-" + self.id... that's just silly. In fact,
my view code really shouldn't care if it's using an HTML template with
"Choose me!" buttons, an Excel template with a "Choose me!"
Re: Arithmetic operations in a templete
So now, I passed in as dictionary data = { a: a_stuff, b:
b_stuff, ... }
where a_stuff and b_stuff is also a dictionary, a_stuff {a_max:9,
a_min:0, .. etc}
when i use
{% for key,value in data.items %}
{{key}}, {{value}}
{%endfor%}
it doesn't print anything, but when i do
{% for key in data.items %}{{key}}{%endfor%}
it prints :
('a', {'a_max': 9, 'a_min': 0, etc}),
did i pass the data incorrectly or something?
On Aug 24, 12:51 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 8/23/07, *San* <[EMAIL PROTECTED]> wrote:
>
>
>
> > How to add suffix/prefix in a template? So if i passed in a list name-
> > [a,b,c,d] and a_max, b_max, etc from views.py. and I do something like
>
> > {% for i in name %}
> > {{ i_max}}
> > {% endfor %}
>
> > so I actually wants to print the value of a_max, b_max, etc. Is there
> > a way to do this? or I have to hardcode the code instead of using for
> > loop?
>
> In your example, there's no need to pass in the list of names - you
> are only iterating over the values. However, assuming that you
> actually need the name: If a is related to a_max, then pass in context
> data that expresses that relationship. Don't pass in two disconnected
> lists - pass in a dictionary:
>
> data = { a: a_max, b: b_max, ... }
>
> Then in the template:
>
> {% for key, value in data.items %}
>{% key %} = {% value %}
> {% endfor %}
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
On 8/23/07, *San* <[EMAIL PROTECTED]> wrote:
>
> How to add suffix/prefix in a template? So if i passed in a list name-
> [a,b,c,d] and a_max, b_max, etc from views.py. and I do something like
>
> {% for i in name %}
> {{ i_max}}
> {% endfor %}
>
> so I actually wants to print the value of a_max, b_max, etc. Is there
> a way to do this? or I have to hardcode the code instead of using for
> loop?
In your example, there's no need to pass in the list of names - you
are only iterating over the values. However, assuming that you
actually need the name: If a is related to a_max, then pass in context
data that expresses that relationship. Don't pass in two disconnected
lists - pass in a dictionary:
data = { a: a_max, b: b_max, ... }
Then in the template:
{% for key, value in data.items %}
{% key %} = {% value %}
{% endfor %}
Yours,
Russ Magee %-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
How to add suffix/prefix in a template? So if i passed in a list name-
[a,b,c,d] and a_max, b_max, etc from views.py. and I do something like
{% for i in name %}
{{ i_max}}
{% endfor %}
so I actually wants to print the value of a_max, b_max, etc. Is there
a way to do this? or I have to hardcode the code instead of using for
loop?
On Aug 23, 11:01 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
> > I know my question could be a bit silly but... I dont know how to do
> > it. Do anybody know how to do arithmetic operations in a templete?
>
> > {{elem}}
>
> > what I want to do is something like {{ elem }} + 100
>
> There's an "add" filter...
>
> http://www.djangoproject.com/documentation/templates/#add
>
> {{ elem|add:100 }}
>
> -tim
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
On 8/23/07, altahay <[EMAIL PROTECTED]> wrote: > > Hello to all, > > I know my question could be a bit silly but... I dont know how to do > it. Do anybody know how to do arithmetic operations in a templete? Generally speaking - you don't. This is by design. Django tries very hard to prevent you from putting logic into a template. Logic and calculations belong in the view; the template shouldn't have any need for calculations. If you maintain this strict separation, it becomes possible to change the template without altering the view, and vice versa. To this end, the Django template language is not, nor will ever be a Turing complete programming language. We have specifically avoided adding arithmetic operations, etc. There are a few very basic math filters - but they exist only to support display-based calculations. How many pixels wide does this DIV need to be, given the size of its component parts - that sort of thing. If you think you need to do arithmetic in a template - think really hard about what you are doing. Are you actually trying to change a display feature, or are you changing the information that is being displayed? If it is the latter, the calculation should be in the view. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
> I know my question could be a bit silly but... I dont know how to do
> it. Do anybody know how to do arithmetic operations in a templete?
>
> {{elem}}
>
> what I want to do is something like {{ elem }} + 100
There's an "add" filter...
http://www.djangoproject.com/documentation/templates/#add
{{ elem|add:100 }}
-tim
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Arithmetic operations in a templete
Sorry I wrote "templete" instead of "template" ...
On 23 ago, 12:31, altahay <[EMAIL PROTECTED]> wrote:
> Hello to all,
>
> I know my question could be a bit silly but... I dont know how to do
> it. Do anybody know how to do arithmetic operations in a templete?
>
> {{elem}}
>
> what I want to do is something like {{ elem }} + 100
>
> thank you in advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
