On Sep 22, 4:48 pm, Bradley Hintze
wrote:
> I am getting an ''ifequal' takes two arguments' error for this line:
>
> {% ifequal {{ param2_trunc_new.3.0 }} {{ param2.4.1 }} %}
>
> I believer those are indeed two arguments. What going on here?
>
> --
> Bradley J. Hintze
Don't put arguments within v
Oh, and you don't have a space between those two variables, so it could be that
they're running together and appear to be a single one.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegrou
Try writing both values to the screen or standard out.
It's always possible that one of them isn't being populated.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscr
Hi Bill,
thank you for pointing me to the stringformat template option, I was
comparing Long with String.
Using now
try:
berufe_id = int(berufe_id.strip())
except:
pass
What helped me a lot.
On Mar 11, 5:18 pm, Bill Freeman wrote:
> It's time to go back to figuring out jus
It's time to go back to figuring out just what these things are.
Put back your code that shows you the variable values, except
instead of
{{ item.id }}
and
{{ berufe_id }}
use
--{{ item.id|stringformat:"%r" }}--
and
--{{ berufe_id|stringformat:"%r%" }}--
The %r version will inclu
Hi Tom,
really cool idea, but it does not work...
-- Bitte Berufsgruppe wählen
--
{% for item in berufe %}
{{item.name}}
{% endfor %}
On Wed, Mar 10, 2010 at 11:13 AM, Tom Evans wrote:
> {% ifequal item.id|stringformat:"s" berufe_id %}
Cool. I spend my filter investigation time looking for one that would
convert berufe_id
to an int (no joy).
--
You received this message because you are subscribed to the Google Groups
"Djan
On Wed, Mar 10, 2010 at 3:37 PM, Bill Freeman wrote:
> That would be my guess. I presume that item.id is an int, so it's
> likely that you're passing berufe_id as a string. All the stuff that
> comes from the GET or POST attributes or request, and any
> arguments garnered by the url pattern are
That would be my guess. I presume that item.id is an int, so it's
likely that you're passing berufe_id as a string. All the stuff that
comes from the GET or POST attributes or request, and any
arguments garnered by the url pattern are strings. If you're not
converting it yourself, berufe_id will
Already tried this several times. Here is a result of your code
item.id = 1 with berufe_id = 1
item.id = 2 with berufe_id = 1
Not sure if this a type (int vs. string) error?
On Mar 10, 4:18 pm, Bill Freeman wrote:
> Try adding code to render the values that you are trying to compare,
> so that
Try adding code to render the values that you are trying to compare,
so that you can see in what way they are not equal. They it will
probably become obvious in what way the conversion through the
GET or POST data and view isn't quite what you want. E.g.; before
the select:
berufe_id: {{ berufe_
On Wed, Jun 10, 2009 at 5:43 PM, Frank Peterson
wrote:
>
> I'm on Django 0.91 (unfortunately we are stuck with that and cannot
> upgrade).
>
I have a really hard time believe you truly are stuck.
Migration may not be the simplest in the short-run, but certainly sensible
in the long-term. Who want
On Wed, Jun 10, 2009 at 5:43 PM, Frank Peterson
wrote:
>
> I'm on Django 0.91 (unfortunately we are stuck with that and cannot
> upgrade).
>
> We have a variable - object.caption and lets say that it equals
> "Bling: whatever" (without the quotes)
>
> I am doing a hack in the templates (dont have
I can apply a filter to convert the request.GET.subseries value to an
integer but is still does not match???
{% ifequal id request.GET.subseries|intvalue %}
I have tried the other way round converting the id to an integer and
keeping the request.GET.subseries as is and this again does not work.
i hope you are encountering the problem as request.GET.subseries is
string and id is integer and they are not matching.
On May 29, 3:52 pm, mbdtsmh wrote:
> I have the problem below when I use a tuple to try and match a request
> item; i.e., it never matches. I can do the same thing with a list
On May 25, 2:29 pm, Pablo López wrote:
> {% ifequal str(problemImpact.description)
> (impact.0) %}
This is not valid Django template syntax - I am surprised it works at
all. You can't call functions with parameters within Django templates.
--
DR.
--~--~-~--~~
On Feb 3, 10:03 am, brad wrote:
> You could use the built-in __str__ method on now.year.
> In [11]: now.year.__str__()
> Out[11]: '2009'
>
> In [12]: now.year.__str__() == '2009'
> Out[12]: True
>
> In your template you'd do something like this:
> {% ifequal year month.year.__str__ %}
Doh! I d
On Feb 2, 6:37 pm, Bret W wrote:
> I've run into a problem with ifequal in one of my templates.
>
> I'm using date-based generic view to display all objects for a given
> year.
> urls.py:
> (r'^taken/(?P\d{4})/$' ...
>
> Part of the extra_context I pass is a DateQuerySet object:
> months = Photo.
Just now {% ifequal %} tag doesn't apply filters to its operands.
On Tue, Jan 20, 2009 at 2:58 PM, ltcstyle wrote:
>
> is this a bug or what?
>
> {{float_number|floatformat:"0"}} give me correct number 1
>
> but
> {% ifequal float_number|floatformat:"0" 1 %}
> never match
>
> Any ideas?
>
> Than
On Sun, 2008-11-23 at 21:52 -0800, Andy Young wrote:
> Hi all,
>
> I've attempted a shortcut in an {% ifequal %} tag and ran into some
> unexpected consequences. Basically, I have two DateFields in a model
> named begin_date and end_date. I am iterating through field names
> ({{ f }}) and thei
On Oct 27, 10:36 pm, "Alfredo Alessandrini" <[EMAIL PROTECTED]>
wrote:
> There is a method for write this, without write a loop:
>
> {% ifequal apple.number <20 %}
> ..
> {% endifequal %}
>
> Alfredo
On Oct 27, 11:52 pm, "R. Gorman" <[EMAIL PROTECTED]> wrote:
> You would prob
You would probably be better off writing a custom template tag (http://
docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-
template-tags).
R.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Djan
On Wed, 2008-10-15 at 19:39 -0400, Karen Tracey wrote:
> On Wed, Oct 15, 2008 at 4:02 PM, Frank Peterson
> <[EMAIL PROTECTED]> wrote:
>
> I have something like the following
>
> {% ifequal flatpage.title "Special Reports" %}
> src="http://
On Wed, Oct 15, 2008 at 4:02 PM, Frank Peterson
<[EMAIL PROTECTED]>wrote:
>
> I have something like the following
>
> {% ifequal flatpage.title "Special Reports" %}
>http://example.com/icon_specialreports.png"; />
> {% endifequal %}
>
> I get the error
> 'ifequal' takes two arguments
> so
2 bruno:
> Not my opinion. Custom tags are to Django's templating language what
> functions are to Python.
I don't think that this is official django developers opinion.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Group
> I can't see
> how the ifless tag would be useful to the majority of users. Zinovil
> really hasn't provided many real life examples either.
I can tell you lots of examples.
{% ifless accounts.count 50 %}
show Paginator
{% else %}
don't show Paginator
{% endifless %}
> Oh and as far as
I've always felt that Django provides a lot of stuff out of the box
that most other frameworks don't. To name a few: auth, admin, sites,
contenttypes, permissions, comments etc. Maybe some have gotten too
much of the good thing and are now wanting for more? :)
On the other hand, even though
I think it's ok that the Django team wants to keep the codebase clean
and maintainable. But from an endusers point of view I understand
Zinovii's position, too. Sometimes I feel that Django's feature set is
very basic and provides only the bare minimum to get started. For real
work you have to wri
On 19 août, 19:44, Zinovii Dmytriv <[EMAIL PROTECTED]> wrote:
> You didn't convince me.
>
> If somebody ask you "When I should write my custom tags?" - the answer
> should be - "You shouldn't, unless you really need some tags that you
> can't live without and you know what are you doing."
Not my
> But we're not talking about 'extensions of framework code' here. We're
> talking about a custom tag, which is using an explicit piece of
> functionality already provided by the framework: the ability to write
> your own tags.
We started this thread from the bug in ifequal. But now we are talkin
On Aug 19, 7:48 pm, Zinovii Dmytriv <[EMAIL PROTECTED]> wrote:
> I'm very happy that django is very flexible - this is great. But Rule
> of thumb is to avoid extensions of framework code unless it's really-
> really necessary. ifless is not that case. It just should be built-in.
But we're not tal
2 Join.Together
> That system will not go through any such changes in the foreseeable
> future, because that would be a backwards-incompatible change
If you are talking about "ifequal doesn't evaluate expressions" - that
it was bug. And it was fixed for 1.0 anyway.
If you are talking about "ifl
I'm very happy that django is very flexible - this is great. But Rule
of thumb is to avoid extensions of framework code unless it's really-
really necessary. ifless is not that case. It just should be built-in.
Like Malcolm said about ifequal:
> Equality is a natural operation for all sorts of ob
If they aren't sufficiently essential for you to use them as custom
tags, they surely can't be essential for the core.
regards
Steve
Zinovii Dmytriv wrote:
> You didn't convince me.
>
> If somebody ask you "When I should write my custom tags?" - the answer
> should be - "You shouldn't, unless
You didn't convince me.
If somebody ask you "When I should write my custom tags?" - the answer
should be - "You shouldn't, unless you really need some tags that you
can't live without and you know what are you doing."
PS: Also in django-template-utils enough to have if_less -
if_greater, if_grea
> http://code.google.com/p/django-template-utils/
Yeah I saw it and it would be great to have django utils also for
current stable version (0.96). Those are for 1.0 and 1.0 is not
released yet. Even if release is on 1 September I'm still not going to
install it. I'll wait few months for the first
On Aug 18, 4:05 pm, zdmytriv <[EMAIL PROTECTED]> wrote:
> It's always bad idea to extend somebodies tool because when you wanted
> to update current version with latest you can be in trouble. Latest
> doesn't always support previous.
> i.e. Django 1.0 uses Variable class to process variable from t
On Mon, Aug 18, 2008 at 11:05 PM, zdmytriv <[EMAIL PROTECTED]> wrote:
>
>> That's one good reason why it's not needed in core. If you need it and
>> you understand the trade-offs and consequences, you can implement it
>> immediately with no break in the flow. Django's supported third-party
>> temp
> However the implementation of such a
> tag would be unlikely to need much patching in the future
"... patching in the future"
No comments...
> so Malcolm's
> advice about implementing it yourself would be acceptable, I'd have thought.
No comments...
Zinovii
--~--~-~--~~-
zdmytriv wrote:
> 2 Steve:
>
>
>> That's no way to endear yourself to the Django community. The
>> development team has some pretty good brains.
>>
>
> I agree, I was too aggressive, sorry about that. Just can't believe
> that bug like this can be on this level.
>
I'd argue that it isn'
> That's one good reason why it's not needed in core. If you need it and
> you understand the trade-offs and consequences, you can implement it
> immediately with no break in the flow. Django's supported third-party
> template tags since day 1 (and even earlier). :-)
It's always bad idea to exten
2 Steve:
> That's no way to endear yourself to the Django community. The
> development team has some pretty good brains.
I agree, I was too aggressive, sorry about that. Just can't believe
that bug like this can be on this level.
> > What about ifless? Is it going to be implemented in 1.0 also?
On Mon, 2008-08-18 at 13:37 -0700, zdmytriv wrote:
> 2 Malcolm:
>
> > It makes a lot of sense when you think about what they can apply to.
> > Equality is a natural operation for all sorts of object types. The
> "less
> > than" comparison only applies to things that have a natural
> ordering.
>
2 Malcolm:
> It makes a lot of sense when you think about what they can apply to.
> Equality is a natural operation for all sorts of object types. The "less
> than" comparison only applies to things that have a natural ordering.
> The first set is much larger than the second.
> A normal use for "
what about
ifequal flatpage.url[:len('/products/')] '/products/'
so you always check the beginning of the url
V
On Jul 18, 11:38 pm, Eliza <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm new to Django and am working on a template, and I have the feeling
> I may be approaching something the wrong way.
Thank you very much Karen -
You clearly defined that problem for me and that fixed the issue. For
others who might run into the same problem, they would do well to
remember to add either __str__ or __uinicode__ as the case warrant:s:
{% ifequal foo.bar__str__ "foobar" %}
or
{% ifequal foo.bar_
On Tue, Jun 10, 2008 at 5:33 PM, John Teague <[EMAIL PROTECTED]> wrote:
>
> First the particulars:
> Django svn rev 7610,
> Apache 2.2.8,
> mod_python 3.3.1,
> Python/2.5.2
>
> I have a template that uses django_template_utils (http://
> code.google.com/p/django-template-utils/) to retrieve object
John M skrev:
> the ID is the primary key ID generated by django on models.
>
> basically, it's not the syntax im having issue with, i think the
> selected_id is being passed / parsed as a string not an intenger like
> ID is.
>
So where do you get the selected_id from? GET/POST variables are al
hi john -
John M wrote:
> {% ifequal selected_id recordset.id %} never seems to work.
>
> where selected_id = 1
> recordset has ID from 1 - 10
just a guess - are selected_id and recordset.id really the same type?
{% ifequal %} will not match for example '1' == 1
best,
jake
--~--~-~-
Hmm... What is `recordset`? QuerySet? QuerySet doesn't have id
attribute.
{% for recod in recodeset %}
{% ifequal record.id selected_id %}
Selected!
{% endifequal %}
{% endfor %}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the G
the ID is the primary key ID generated by django on models.
basically, it's not the syntax im having issue with, i think the
selected_id is being passed / parsed as a string not an intenger like
ID is.
J
On Sep 13, 12:45 pm, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> Hmm... What is `recordset`?
On 9/10/07, sagi s <[EMAIL PROTECTED]> wrote:
>
> I tried to compare user ids in a template almost exactly like the
> example in the docs:
>
> {% ifequal user_id copy.checkout.user.id %}
>
> however, it seems like user_id (a context variable I'm passing) is a
> string and the other id that com
> Dan, ifequal cannot evaluate its arguments. They must be variables,
> numbers or constants in quotes.
Thanks Stefan, I'll remember that in future.
> But you can do this:
>
> {% for item in menu_items %}
> {% if forloop.last%} class="last-item"{% endif %}
> {% endfor %}
>
Thanks Nathan, that
2007/7/28, Eloff <[EMAIL PROTECTED]>:
>
> Thinking myself clever I added enumerate as a filter and did:
>
> {% for i, item in menu_items|enumerate %}
> {% ifequal i|add:1 menu_items:length %} class="last-item"{% endifequal
> %}
Dan, ifequal cannot evaluate its arguments. They must be variables,
n
ifequal can't do filters, unfortunately.
But you can do this:
{% for item in menu_items %}
{% if forloop.last%} class="last-item"{% endif %}
{% endfor %}
Or
class="{{ forloop.first|yesno:"first," }} {{ forloop.last|
yesno:"last," }}"
On Jul 27, 11:42 pm, Eloff <[EMAIL PROTECTED]> wrote:
> T
[snip]
> > Sure -- seek_id is calculated in the view. It is delivered to the
> > template
> > via the second argument to render_to_response: { ..., "seek_id" :
> > value,...}.
>
> Yes, I realised it came from the view like that. So my question wasn't
> clear. What have you said doesn't tell us w
On Mon, 2006-10-02 at 20:12 -0700, frank wrote:
>
> Malcolm Tredinnick wrote:
> > On Mon, 2006-10-02 at 16:05 -0700, frank wrote:
> > > I have a simple loop which sets up a series of radio-buttons.
> > > "objgroup" is
> > > obtained through a DB query/filter:
> > >
> > > {% for obj in objgroup %}
Malcolm Tredinnick wrote:
> On Mon, 2006-10-02 at 16:05 -0700, frank wrote:
> > I have a simple loop which sets up a series of radio-buttons.
> > "objgroup" is
> > obtained through a DB query/filter:
> >
> > {% for obj in objgroup %}
> > >{% ifequal seek_id obj.id %} CHECKED
On Mon, 2006-10-02 at 16:05 -0700, frank wrote:
> I have a simple loop which sets up a series of radio-buttons.
> "objgroup" is
> obtained through a DB query/filter:
>
> {% for obj in objgroup %}
> {% ifequal seek_id obj.id %} CHECKED {% endifequal %} >
> showing other t
Hi, carlos
I just come across the same problem with ifequal and bring into the same
solution with yours that I think is silly too.
I just want to convert the auto-generated id into string to have a simple
correct ifequal test. I simply can not convert strings into integer
because strings
OK, I fixed it, by defining a 'computed' method that returns the int
value in str form. So silly!
def prva_registracija_mm_str (self):
return str(self.prva_registracija_mm)
Ohwell :-)
On 7/17/06, Carlos Yoder <[EMAIL PROTECTED]> wrote:
> Forgot to say, I have the same l
Forgot to say, I have the same logic working with no problem, but for
a CharField, so this issue must be related to the field's datatype...
On 7/17/06, Carlos Yoder <[EMAIL PROTECTED]> wrote:
> Hello there,
>
> I'm using a object_detail generic view to display some data. One of
> the object's fie
Great, thanks! I thought it might be something like this. Should have
dug a little deeper...
--~--~-~--~~~---~--~~
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@go
All variables that you "get" from the request come back as strings. So
'2' != 2
You could just set show_only=int(show_only) before you pass it to the
template.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
perfect, thanks!
On 12/16/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I just fixed this in the Django development version (trunk), so, if
> you're using that, just "svn update". The problem was that the "1" in
> that example was being compared as a string, not an integer.
On 12/14/05, Milton Waddams <[EMAIL PROTECTED]> wrote:
> Can someone tell me why this doesn't work?
>
> {% ifequal forloop.counter0 1 %}
Hi Milton,
I just fixed this in the Django development version (trunk), so, if
you're using that, just "svn update". The problem was that the "1" in
that examp
good thinking, thanks :)
> It's usually better practice to put rules like this into your Python code
> rather than your template. Make your template say something like:
>
> {% if blog_post.allow_ad %}{% endif %}
>
> and do something like this in your Python code:
>
> for i, blog_post in
[Milton]
> In my case I want to place an adsense ad between a couple of blog
> posts though want to make sure that I don't go over the 3 ads per page
> limit.
It's usually better practice to put rules like this into your Python code
rather than your template. Make your template say something li
thanks
Is there a way for me to achieve what I'm looking for?
In my case I want to place an adsense ad between a couple of blog
posts though want to make sure that I don't go over the 3 ads per page
limit.
On 12/15/05, kmh <[EMAIL PROTECTED]> wrote:
>
> Milton Waddams wrote:
> > Can someone t
Milton Waddams wrote:
> Can someone tell me why this doesn't work?
>
> {% ifequal forloop.counter0 1 %}
>
> there are enough loops and the output of {{forloop.counter0}} does
> print 1 at the appropriate place?
>
> By work I mean it is never equal, I've tried putting the 1 in quotes
> with no diff
70 matches
Mail list logo
