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 <[email protected] <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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-users.
For more options, visit https://groups.google.com/groups/opt_out.
