django template string and int comparison behavior

2,818 views
Skip to first unread message

J Y

unread,
Sep 17, 2013, 2:50:35 PM9/17/13
to django...@googlegroups.com
I am building a search form that provides a drop down list, and then on the search results, I am redisplaying the search form, but with the search parameters already pre-selected, so this is what I attempted to do:

<select name="system">
    {% for item in object_list %}
        <option value="{{ item.id }}" {% if item.id == request.GET.system %} selected="selected" {% endif %}>
            {{ item.name }}
        </option>
    {% endfor %}
</select>

Unfortunately, this did not work.  When I did some testing, I realized that item.id is giving back an int, while request.GET.system is giving back a string.  If I used the view to change the GET value to an int in the context, then the comparison works.

What I am wondering is, is this expected behavior?  Does the request object always return a string, and that I am better off writing my own custom tag to convert request objects into int for comparison?  What is the best practice to employ here?  I am fairly new to django and could use some pointers.

Thanks,

Jack

Rafael Durán Castañeda

unread,
Sep 17, 2013, 3:42:55 PM9/17/13
to django...@googlegroups.com
Hi,

I don´t think using requests objects into templates is a good idea, use request object in the view so you source the template context with whatever you need.

HTH

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.

Bill Freeman

unread,
Sep 17, 2013, 4:00:01 PM9/17/13
to django-users
Yes, this is the expected behavior.  The GET parameter is a string, being something that is just parsed out of the query parameter portion of the URL (which is, itself, a string).  There is nothing to inform the code that parses the query parameters which of the things that might look like numbers should be converted to int, float, or left alone.  Since converting to a numeric type and back is not a null operation ('001' -> 1 -> '1', '1.00' -> 1.0 -> '1.0'), leaving it as the string it is already is the correct choice.  Knowing how a parameter is to be interpreted is an application specific task.

Probably the correct approach for you is to have view code capture the system argument and convert it to an int (perhaps there is a form field instance handy which has already done that and put it in the form's cleaned_data?), and pass that into the template context.  Then compare item.id to that, rather than something you dug out of request.GET.

Bill


--

J Y

unread,
Sep 21, 2013, 1:41:48 AM9/21/13
to django...@googlegroups.com
That makes a lot of sense.  Thanks for the explanation.  I will use the view to convert it to an int.

Jack
Reply all
Reply to author
Forward
0 new messages