Tim,
Thanks for the reply. Very helpful. In the past I did try the
statement:
if 'price' in request and request['price'] <> NOT_PICKED:
////////////
However when that line was accessed I would get the following error:
KeyError at /rugs/searchresult/
'0 not found in either POST or GET'
/////////////
I think it has something to do with 'request'. Because when I take
that out and just use 'if 'price' in request['price'] <> NOT_PICKED: '
then it doesn't error out.
Any suggestions as to why that's happening?
Thanks
On Aug 8, 4:28 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
> > If anybody has any suggestions on how to make the code more
> > optimized would be appreciated. Here is my view:
>
> First, a style issue: it's considered bad form to shadow the
> python built-in "dict" by using a variable with the same name.
>
> Second, my eyes are bleeding from the convolution of that code.
>
> If I understand what you're trying to do, you simply want to
> filter the Choice objects by price, size and color if they've
> been specified. Thus, wouldn't you be able to do something like
>
> c = Choice.objects.get(id=h.id).style_set.all()
> NOT_PICKED = '--------------'
> if 'price' in request and request['price'] <> NOT_PICKED:
> c = c.filter(price=request['price'])
> if 'size' in request and request['size'] <> NOT_PICKED:
> c = c.filter(size=request['size'])
> if 'color' in request and request['color'] <> NOT_PICKED:
> c = c.filter(color=request['color'])
> return render_to_response('searchresult.html', {
> 'results': c
> })
>
> which is a heckuva lot easier to read and likely piles better in
> terms of performance (no looping, let alone nested looping).
>
> If your request vars have multiple-selections for a given value
> (an iterable via the getlist() method of the QueryDict), you can
> smash them together:
>
> #at the top
> from operator import or_
>
> #change each "c = c.filter(...)" line above to this form:
> c = c.filter(reduce(or_, [
> Q(size=s) for s in request.getlist('size')
> ]))
>
> which "or"s together Q() objects for each individual size before
> passing it to the filter. It's not a great remedy in the "eyes
> bleeding" department, but both make the logic a bit easier to
> follow the pattern:
>
> if they submitted a {{ field }},
> filter the Objects by {{ field }}
>
> As for request[varname] vs. request.POST[varname] vs.
> request.GET[varname] I'm not sure what the difference is (other
> than the obvious diff between GET & POST) without reading the
> code, but it should work unless you explicitly want something
> different. For filtering/searching purposes, I tend to prefer
> GET parameters because it's easy to bookmark the results if you
> want or send the link to someone so they can see the same results.
>
> -tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
