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
On Tue, Sep 17, 2013 at 2:50 PM, J Y <prism...@gmail.com> wrote:
> 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
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
