Hi Bill,
thank you for pointing me to the stringformat template option, I was
comparing Long with String.
Using now
try:
berufe_id = int(berufe_id.strip())
except:
pass
What helped me a lot.
On Mar 11, 5:18 pm, Bill Freeman <ke1g...@gmail.com> wrote:
> 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
> > athttp://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.
