According to Douglas Kline: > > By default htsearch allows only a limited number of attributes to be > > passed in from the search form. To do otherwise would remove a > > significant level of control from the maintainer and could in fact be > > rather dangerous. Instead, htsearch forces the maintainer to specify > > those attributes which they choose to have htsearch act upon. This is > > handled through the allow_in_form attribute, which needs to be placed > > in your configuration file. Take a look at the following. > > > > http://www.htdig.org/attrs.html#allow_in_form > > > > The above link even provides an example of setting up search_algorithm > > options. > > > I've added the line > > allow_in_form: search_algorithm > > to the conf file and the clause > > <SELECT NAME="search_algorithm"> > <OPTION VALUE="exact:1 synonyms:0.5 endings:0.1" SELECTED>words > <OPTION VALUE="substring:0.5">strings > </SELECT> > > to the search form file. I get the option to use either words or strings when > the search page is brought up and it seems to work. However, after I've run a > search and now the form brought up by the htsearch executable is the page, I > don't get the choice any more and even if I ran a strings search the first time > further searches only find whole words, i.e. I can run a successful strings > search from the search page and get results and then come up empty-handed > repeating the search for the same string. What could be wrong? Are these > values not passed onto htsearch for re-use? Can they be?
They can be, but you need to change your result template to make use of the new template variables that allow_in_form will define for you. You can pass these on as input text fields or hidden input fields if you want, in the followup search forms. However, if you want htsearch to build new select lists that use the current value as default, it gets a bit more hairy. See http://www.htdig.org/attrs.html#build_select_lists and http://www.htdig.org/hts_selectors.html > Also, I don't understand the danger of putting this option at the user's > disposition (assuming that it can be). What could an unscrupulous or > well-intentioned, mistaken user do that would be harmful? Well, in the case of search_algorithm, probably not much, but some sites may very well want to avoid users making use of substring matches because of the extra load it would put on the server. You might also want to prevent users from selecting search algorithms that require databases you haven't built on your site. The real danger would be if you started adding attributes that define filenames into allow_in_form. E.g., if the user could redefine nothing_found_file arbitrarily, he could look at any file on your web server. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ ht://Dig general mailing list: <[EMAIL PROTECTED]> ht://Dig FAQ: http://htdig.sourceforge.net/FAQ.html List information (subscribe/unsubscribe, etc.) https://lists.sourceforge.net/lists/listinfo/htdig-general
