According to Geoff Hutchison:
> On Mon, 11 Sep 2000, Gilles Detillieux wrote:
...
> > A somewhat more troublesome side effect of Rajendra's approach is that
> > the LOGICAL_WORDS variable takes on the value appropriate for the last
> > database in the collection, rather than a value that represents all
> > fuzzy matches found in all databases. I couldn't tell just by looking
> > at your code whether your patch addresses this problem.
>
> I don't know that this is a great idea. If the config files specify
> differing fuzzy matches, then what should you tell the user? Giving them
> the union of all matches could be misleading--what if it didn't really
> search for "bar" in every database? The only "right" solution would be to
> somehow tell them LOGICAL_WORDS for each database, but that's probably
> confusing to boot!
>
> I suggest that we clearly document this sort of problem when talking about
> collections. There are plenty of other places where we document how you
> can shoot yourself in the foot (allow_in_form comes to mind).
Yes, you should definitely use the same setting of search_algorithm
for all databases in the collection, but you could still get different
fuzzy matches appended to LOGICAL_WORDS for each database, for any
fuzzy search algorithm that uses words from the database rather than
a static dictionary. The endings and synonyms algorithms should use
common databases, but soundex, metaphone, and accents should use different
databases for each word database in the collection (these usually go in
your database_dir anyway), and fuzzy matches from prefix, substring and
speling all come straight from the word database.
So, if you search for "bar" in two databases, and the substring algorithm
picks up "foobar" in the first database, and "barbell" in the second one,
LOGICAL_WORDS will only be set to "(bar or barbell)", with no mention
of foobar which only occurs in the first database.
...
> > Yes, I thought it would be quite useful myself if htsearch built an
> > initial search form from a template, e.g. common/search.html, in the
> > case where it was called with no query string. That way all the stuff
> > you set up for select lists, checkboxes, and so on would be configured
> > the same way for the initial search form as for all the follow-up search
> > forms in common/*.html.
>
> While this is an easy case to take care of in htsearch.cc, it would
> require an additional template. Right now, you'd get the nomatch file,
> obviously with an appropriately generated search form. If we did this,
> would we also want to get rid of search.html?
Well, if we did this, then search.html should become a template file in
the common directory, and should be formatted as such. If users want
a static search form to work with, they could always run htsearch with
no query string (or no words parameter in the query string, perhaps,
so you could still use "/cgi-bin/htsearch?config=foo" to get a form) and
save its output. We could even have that done automatically, to install
that static form, so that we wouldn't need to maintain yet another form
manually in the source tree.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
