That makes a lot of sense. Thanks for the explanation. I will use the
view to convert it to an int.
Jack
On Tuesday, September 17, 2013 1:00:01 PM UTC-7, ke1g wrote:
>
> 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 <pris...@gmail.com <javascript:>>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...@googlegroups.com <javascript:>.
>> To post to this group, send email to django...@googlegroups.com<javascript:>
>> .
>> 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.
