Shopping Cart Documentation by Infodial, Inc.

PRESERVING ORIGINAL SEARCH

SearchString

What it's for: It retains the information the ISAPI needs to reproduce a search. This enables a user that has gone all the way to a subtotal page to return back to the original dbsearch inquiry.

How To Use it:

In the original database search for products include ##SearchString## in the template.

In the NON-Database calls to the ISAPI ( Additem, Showtotal, etc. ) pass the search string data. This is usually done in a template to the original search and between each template for the shopping cart functions.

Whenever you want to go back to the database search include either:

<input type="hidden" name="SearchString" value="##SearchString##">

or the GET method: dbsearch.exe?SearchString=##SearchString##

To preserve an Initial Search while going for a drill-down use SaveSearchString:

You put ##SearchString## on any database search template and the entire original search request is stored. It won't matter if the original request was via POST or GET, the template will have all of the data in ##SearchString## formatted in a way that can be passed right back as a POST or GET to recreate the search results or add form elements to the search. Lets say you had 5 DBA_myfield="somedata" stored in a SearchString. You could add a 6th by doing a normal <input ...>

Since it can be carried through additem, subtotal, and total, it has the value of preserving dbsearch requests even though the last executable was not dbsearch.

The main difference between SearchString and SearchData is that "SearchData" retains only 1 element of the search, something that directly connects to DB_ or DBX_ or DBA_ where SearchString preserves the entire search, so if SQLParams were used, the SearchPrev and SearchNext information, its most popular use, passwords if doing a login/password application, basically ALL the information to completely reconstruct a search with no other tags. The beauty is that you can not only preserve the search but you can extend it and the template doesn't have to know what was done on the initial search to move on. Lets say you had 5 different search buttons on the initial page all pointing to the same template and then you wanted to move on from there. ##SearchString## solves that problem too.

Another main difference is that additem, subtotal, and total all support the preservation of the searchdata. Where that information is normally lost, it is preserved throughout the shopping cart. A good shopping cart programmer could even preserve it one step further by assigning it to the "comments" field (a memo) when something is purchased. This could then later be used by the merchant to discover what search was preformed prior to moving on to the shopping.