[ic] filtering search results or refining results or searching within results

[Jeff Dafoe]

> hey jeff, this sounds like a great feature and I have actually thought
> about doing this recently, would you mind posting your code of
> how you did it ?

    My code for doing it is absolutely hideous, I used the trial-and-error
development style, primarily focusing on the error part.  It is not very
modular or reuseable.

this goes at the very top of the results.html file:

[if session last_search =~ /products/]
    [seti lastsearch][data session last_search][/seti]
[/if]

    You may have to change the =~ /products/ to something more appropriate.
The issue is that when multiple pages of search results are returned, and
the user is currently on some page other than the first, last_search
contains some sort of reference that is used by the paging mechanism as
opposed to an actual search.  This is fine, since if you have applied a
filter you need to restart from the first page anyways.  In my store
implementation, a normal search always has fi=products somewhere in it when
the search is on the first page.  So basically, my code above saves the
search results if the results indicate the first page of matches.

next, in my category_vertical file I have the filter selectbox, which in my
case contains options for styles of clothing, we will call them "country"
and "western".  Javascript is used so that when the user selects a new
option in the selectbox, the selectbox (named "scene") posts out the filter
value (either "country" or "western") back to itself (form
action="@_MV_PAGE_@").  One of the options returns "none", which is designed
to turn off filtering.

Also in my category_vertical file I have the following code, which does most
of the magic.  It is looking for incoming posted "scene" CGI variables and
setting various session variables and such.  The regular expression that
actually does the "scene" switching may need to be beefed up on some
systems, I know that the scene name will never appear elsewhere in my
last_search value, so it works for me.

[if cgi scene]
  [tmp lastscene][scratch filter1][/tmp]  [comment]save current scene for
use by selectbox[/comment]
  [if cgi scene eq none]
    [set filter1][/set]
  [else]
    [seti filter1][cgi scene][/seti]
  [/else]
  [/if]
  [tmp result]
    [perl]
      my $search = $Scratch->{lastsearch};
      my $lastscene = $Scratch->{lastscene};
      my $newscene = $Scratch->{filter1};
      ## strip repeating va= elements
      $search =~ s/\/va=(.*)\/?//;
      if ($lastscene) {
        # search old search results for lastscene and replace with newscene
        $search =~ s/$lastscene/$newscene/i;
      } else {
        # there was no previous filter, so just append it on the end
        $search = $search . '/se='.$newscene.'/op=re/sf=inactive';
      }
      ## the /ml=whatever seems to disappear sometimes, put that back on if
need be
      if (! ($search =~ /\/ml=8/)) {
        $search = $search . '/ml=8';
      }
      $Scratch->{bounceto} = $search;
      return;
    [/perl]
  [/tmp]
  [tmp mvpage]@_MV_PAGE_@[/tmp]
  [if scratch mvpage ne index]
    [bounce href="http://store.subcultural.com/subcultural/[scratch
bounceto]"]
  [/if]
[/if]

    Basically, this is a cobbled together solution to a simplistic problem
that I had.  You can see it in action at www.subcultural.com .  That was for
my girlfriend so she gets the ghetto design and 15-minute solution.  A
paying customer whose interchange solution I am currently working on has
more sophisticated filtration requirements, I haven't addressed that issue
yet.
    Oh yeah, if someone can mention how to access @_MV_PAGE_@ directly from
an "if" statement, I can eliminate the following embarassment.  I spent some
time in the archives, checking the reference manual, and using good old
trial and error t and couldn't determine which namespace it was in.

  [tmp mvpage]@_MV_PAGE_@[/tmp]
  [if scratch mvpage ne index]


Jeff