[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
[ic] Re: table drive component template for complex searches
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