[ic] Re: table drive component template for complex searches

Barry Treahy, Jr. interchange-users@icdevgroup.org
Wed Jun 12 17:26:02 2002


Ed LaFrance wrote:

> At 08:42 PM 6/10/2002 -0700, you wrote:
>
>> Barry Treahy, Jr. wrote:
>>
>>> I need to create a component for page construction, preferably table 
>>> driven, what will allow for choices to be made from radio, check 
>>> box, and entered values.  There are enough similarities between our 
>>> product lines that being table driven could make this task much 
>>> simpler in the long run.
>>>
>>> An subset example from one of our product lines would need these 
>>> types of choices:
>>>
>>> Frequency:
>>>    [   ] 26.5 Ghz
>>>    [X] 18.0 Ghz
>>>    [X] 12.4 Ghz
>>>    [   ] 11.0 Ghz
>>>
>>> Power Rating:
>>>    [X] 2 watts
>>>    [X] 5 watts
>>>    [   ]O 10 watts
>>>
>>> Interface Genders:
>>>    *  Male/Female
>>>    O Female/Female
>>>    O Male/Male
>>>
>>> Low VSWR:    [  ]
>>>
>>> Attenuation value:  ______
>>>
>>> And then with the input from this dynamically created form, a search 
>>> would need to be constructed to scan through the products table.  A 
>>> side note, the intent isn't to search for a precise hit through  a 
>>> description or title column as individual metric columns for each 
>>> parameter exist, but rather reduce the 30,000 SKU's and infinite 
>>> choice combinations down to a manageable few SKU's and then present 
>>> those SKU's to the prospective buyer. Before I attempt to do 
>>> something that has already been created by someone else who wouldn't 
>>> mind sharing their efforts, has any one done any thing like this?
>>>
>>> Can anyone provide a push start on this or at least a recommended 
>>> direction to head?
>>
>>
>> I've been forging ahead on this, perhaps a case of the 
>> blind-leading-ones-self, but so far I have a form establish which is 
>> not data driven as I had hoped, at least not yet :-)
>>
>> I'm still trying to figure out how to handle the content selection.  
>> I have the following search:
>>
>>  <input type=hidden name="mv_searchtype" value="db">
>>  <input type=hidden name="mv_sort_field" value="category">
>>  <input type=hidden name="mv_sort_field" value="sku">
>>  <input type=hidden name="mv_sort_field" value="">
>>  <input type=hidden name="mv_coordinated" value="yes">
>>  <input type=hidden name="mv_search_map" value="
>> mv_searchspec=FREQMAX
>> mv_searchspec=POWER
>> mv_searchspec=VSWR
>> mv_searchspec=BODY
>> mv_searchspec=GENDERS
>> mv_searchspec=INTERFACES
>> mv_searchspec=DBRANGES">
>>  <input type=hidden name="mv_search_field" value="freqmax">
>>  <input type=hidden name="mv_search_field" value="power">
>>  <input type=hidden name="mv_search_field" value="vswr">
>>  <input type=hidden name="mv_search_field" value="body">
>>  <input type=hidden name="mv_search_field" value="genders">
>>  <input type=hidden name="mv_search_field" value="interfaces">
>>  <input type=hidden name="mv_search_field" value="dbranges">
>>
>> by gleaning hints from the archives and docs, it does select product 
>> but the challenge I'm running into is that first, this should be an 
>> AND reduction between the fields, yet the returned results appear to 
>> be an OR.
>>
>> Additionally, the water is murkied because within the field such as 
>> POWER, if the person checks that he wants to see both 2 and 5 watt 
>> choices, the search seems to be applying an AND to the field search 
>> where I really need the logic to operate as an OR.
>>
>> So, so summarize where I need to reach, each field test if non-black 
>> needs to reduce the results selected in an AND test between 
>> themselves. Within each field, if multiple choices are available, 
>> each choice needs to be considered as an OR test:
>>
>>    (FREQMAX eq 18 OR FREQMAX eq 12.4) AND (POWER eq 2 or POWER eq 5) 
>> and BODY eq STD
>>
>> for example...
>>
>> Anyone???
>>
>> Barry
>
>
> Given the proliferation of ANDing and ORing, you really should 
> consider going SQL with this - it is a better vehicle for complex 
> searches IMHO.  In either case, I would also suggest that you collect 
> all search data as a separate step - evaluate it (which allows you to 
> perform manipulations if needed), then pass it to a search. There are 
> some examples of this in the UI and elsewhere in foundation. A direct 
> search form post is too restrictive I think.
>
> - Ed L.

Thanks Ed and Paul, you both recommended a collection page and then passing on the results.  Ed also recommened SQL, which isn't an option at the moment, so I'm forging ahead from there.

Before I dive into this development further, I need to ask what may be a profoundly dumb question, but here it goes.

Looking at the contents of the CGI values from dump (I've pasted some of the values below), I see the results from the multiple check box selections delimited by a null.  Could I not replace the null with the pipe, isn't that the equivalent of OR in a regexp, and then pass that value into a loop search?  Wouldn't the fact that the nulls are gone stop IC from parsing each element into a unique set of 'se/op/sf' for scan?


Thanks...

Barry

###### END ENVIRONMENT #####
###### CGI VALUES      #####
{
          'mv_nextpage' => 'ATTsearch',
          'FREQMAX' => '26\018\012.4\011\08\04\02',
          'mv_session_id' => 'rIX5IGoR',
          'INTERFACES' => 'SMA,SMA',
          'POWER' => '2\05\010\020',
          'VSWR' => 'LOW',
          'GENDERS' => 'M,F',
          'DBRANGES' => '3',
          'BODY' => 'STD'
        }

###### END CGI VALUES  #####
###### SESSION         #####
{
          'last_error' => 'search error: Limit subroutine creation: bad limit creation code in coordinated search, probably search group without search specification. at /ibin/interchange/lib/Vend/Search.pm line 768.
',
          'last_search' => 'scan/fi=products/se=Attenuator/se=26/se=18/se=12%2e4/se=11/se=8/se=4/se=2/se=2/se=5/se=10/se=20/se=LOW/se=STD/se=M%2cF/se=SMA%2cSMA/op=rm/op=rm/op=rm/op=rm/op=rm/op=rm/op=rm/lb=loop2ATTsearch/sf=prod_group/sf=freqmax/sf=power/sf=vswr/sf=body/sf=genders/sf=interfaces/tf=sort/co=yes/ac=0/ac=0/st=db',


-- 

Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO 

E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028