[ic] coordinated searches including a profile? (or: using scratch variables in a search)

Mike Heins mikeh@minivend.com
Sun, 19 Nov 2000 18:30:08 -0500

Quoting Doug Alcorn (doug@lathi.net):
> I have seen two questions about this in the minivend mailing list
> archive that went (apparently) unanswered.  Basically I have defined a
> search profile earlier in the page.  I can perform the [area scan...]
> if I hard code all the parameters.  I can perform the scan if I just
> use my profile. I can't scan if I use a profile with any other
> condition.  Here's what I have:
> [seti myprofile]
>         sf=addl_category
>         se=[scratch model]
> [/seti]
> <form action="[area href="scan" arg="
>         fi=products
>         st=db
>         co=yes
>         mp=myprofile
>         sf=category
>         se=batteries"]" method="post">
> ...
>         <input type="submit">
> </form>
> What I get back is from the results page, "No match for 'batteries
> MITSG100'" (where MITSG100 is the value of [scratch model]).  However,
> I do have a product that meets those two criteria.  If I do a select
> at the mysql prompt I can get the product listed.  I know that the
> link is being generated correctly.  I get
> 'http://....../scan/fi=products/st=db/co=yes/sf=addl_category/se=MITSG100/sf=category/se=batteries.html'.
>  In fact, If I code it like this:
> <form action="[area href="scan" arg="
>         fi=products
>         st=db
>         co=yes
>         sf=addl_category
>         se=MITSG100
>         sf=category
>         se=batteries"]" method="post">
> It works like a champ!  The exact same url is generated.  I don't get
> what's going on here.  Any clues?

As you noted later, it doesn't generate the same URL.

The problem is in the parsing of the search field. Basically, you can't
set coordinated search fields and strings both in the profile and the
scan line. If you put both in the profile it works.

This is due to the order in which the fields are parsed. Searchspec is parsed
before profile, so the search strings in the profile get pushed on the
array. Fields come after the profile, so they are set afterwards.

This is probably sub-optimal at this point in Interchange's life cycle, but
at the time it was done there was an actual reason. (If you are interested in
that reason, examine the mv_last parameter that is parsed in the profile -- it
allowed you to override form-based parameters with profile settings.)

I will think about this one -- it may be possible to make the order
determinate if both mv_coordinate and mv_profile are set. But I have
to be careful as changing the order could blow away a lot of existing

A workaround is to just set the common portion in your scratch:

 [seti myprofile]
         se=[scratch model]

Then use it as:

 <form action="[area
         [scratch myprofile]
	| ]">

Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Fast, reliable, cheap.  Pick two and we'll talk.  -- unknown