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 include quotes if it's a string, and will show
any whitespace. The dashes are just to be sure we know where
the object representation begins and ends.
May we see the corresponding url pattern?
I just want to be clear, however, that the best place to fix this is
in a view function. Even if it is mostly a wrapper for a generic view
function (capture all the arguments and then pass them on, after
fixing up the berufe_id argument, and return what the generic view
returns.
This would also give a place to put a pdb.set_trace() so that you can
really see what's going on without having to invent code to give you
hints.
In case you're not very pythonic, here's what fix-up code in such a
view function would look like:
try:
berufe_id = int(berufe_id.strip())
except:
pass
Where the "pass" is you could instead return some error, or set
berufe_id to the integer 1.
Actually, while testing (DEBUG=True in settings.py), leave out the
try, except, pass and just put in the berufe_id= line. Then if it
can't convert it to an integer you will get a 500 with a nice debugging
stacktrace that let's you look at variables in each stack frame, particularly
that of the view function.
My reasons for saying that this is the right place to fix it is that:
1. This only
happens once per request, as opposed to once per select item per request;
2. You have the full power of python to fix whatever needs to be fixed;
3. I believe that comparing two integers is a bit faster than comparing two
strings (unless both strings are interned, in which case you have the cost
of interning each string generated through stringformat, which is even more
expensive than a string compare; and 4. The template code, which may be
manipulated by non-programmers, becomes clearer to understand.
Bill
On Wed, Mar 10, 2010 at 4:17 PM, wolle <wo...@upb.de> wrote:
> Hi Tom,
>
> really cool idea, but it does not work...
>
> <select name="berufe" id="berufe" onchange="onSubmitFilterForm();">
> <option value="0">-- Bitte Berufsgruppe wählen
> --</option>
> {% for item in berufe %}
> <option value="{{item.id}}" {% ifequal
> berufe_id item.id|
> stringformat:"s" %}selected{% endifequal %}>{{item.name}}</option>
> {% endfor %}
> </select>
>
> does not select any option...
>
> Any more hints?
>
> On Mar 10, 5:13 pm, Tom Evans <tevans...@googlemail.com> wrote:
>> On Wed, Mar 10, 2010 at 3:37 PM, Bill Freeman <ke1g...@gmail.com> 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 strings. If you're not
>> > converting it yourself, berufe_id will be a string, and:
>>
>> > >>> 1 == '1'
>> > False
>> > >>>
>>
>> > Do you have a view function, or are you fitting this into a generic
>> > view somehow?
>>
>> > Too bad that there doesn't seem to be a filter to invoke the int
>> > constructor,
>> > or a string method that does it. You could add a method to your model
>> > that returns id as a string, then
>>
>> > ...{% ifequal item.id_as_string berufe_id %}...
>>
>> {% ifequal item.id|stringformat:"s" berufe_id %}
>>
>> Cheers
>>
>> Tom
>
> --
> 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 unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
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 unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
