On Mon, 11 Sep 2000, Gilles Detillieux wrote:
> consistent across all configs in the collection. His example config
> files were fairly simple, defining only database_dir and start_url,
> and then using an "include" operation to read a common.conf file that
> had all the other definitions, including collection_names.
At the moment, there really isn't any documentation on making collection
config files, but this is how I would suggest writing it. For one, it
avoids a lot of possible weirdness and for another it suggests that people
do it the right way. (Plus, it's just plain easier to maintain this sort
of thing.) N.B. that the multidig shell scripts set up database and
collection files this way.
> 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).
> > - The CGI parameter "config" is only used to specify a kind of a
> > "central" config file. From this file, only the display specific
> > parameters and "collection_names" are used. Therefore, this config file
I think this really breaks backwards-compatibilty. We have never said that
a config file is only good for certain attributes. After all, there may be
reason to put certain attributes in the main config or the individual
config files.
> > - Enabling/disabling single indexes is done with a new CGI parameter,
> > "collection". Only those indexes are searched which are also listed in
> > the config file parameter collection_names.
As Gilles said, I think this is a good idea.
> 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?
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
