Hi all,
I think there are a few problems in the current implementation of
htsearch for using multiple indexes, mainly around the concept to choose
multiple indexes by simply specifying them all with the "config=..." CGI
parameter:
1) Around line 493 in Display.cc, a QuotedStringList is set up that
obviously was intended to set the state of HTML form checkboxes to
"checked". These checkboxes would allow the user to select the indexes
to be searched. But the checkboxes are nowhere generated.
2) _If_ such checkboxes are used (something like <input type="checkbox"
name="config" value="index1">), the details of the HTML output produced
by htsearch depend on the HTML settings of the config file searched
last.
The attached patch to Display.cc, Disply.h and htsearch.cc should fix
these problems:
- 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
is read in first; in the loop in function main() that searches the
indivdual indexes, the config file describing this index is being used;
the "central" config file is read in again, before the HTML data is
produced.
- 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.
- The HTML template files now may contain the variable
$(COLLECTION_PARMS). This variable is expanded into a list of checkboxes
to allow the user the selection of indiviudal indexes.
I chose to not "assemble" the value of $(COLLECTION_PARMS) in
Display::setVariables, but instead to modify Display::outputVariable, so
that the HTML text for the check boxes is produced "on the fly", when
$(COLLECTION_PARMS) is parsed. With this approach, I also removed the
special treatment of $(HTSEARCH_RESULTS) in a wrapper template file.
Some things are
missing:
- The new method Display::displayCollectionList can expand the variables
$(COLLECTION_NAME) (the name of a config file) and $(COLLECTION_TEXT).
The latter is intended to be are more descriptive text than the config
file name to be displayed beside an index selection checkbox, but the
value for this variable is at present nowhere prepared. I'm not sure,
what is better: to use only one config file parameter, something like:
collection_names: index1 index2 ...
collection_descripction: index1 "some gemeral stuff" \
index2 "some exotic data" ....
or to use a separate parameter for each index:
collection_names: index1 index2
collection_description_index1: some general stuff
collection_description_index2: some exotic data
...
- While the user can select the indexes to be searched on a result page,
it would be fine to have these checkboxes on search.html too. Well, I
know, how to write an HTML page by hand :), but I wonder if its worth to
modify htsearch, so that it can display the first search page, with
checkboxes, if the template contaions $COLLECTION_PARMS. Or to write a
little perl script for this job. That would make it easier for the admin
to get a consistent "entry page" and search results.
- if an index is not accessible, htsearch simply bails out. Perhaps it
would be better to only notify the user, that [s]he did not get results
from that index.
The attachments are diff output against the files from
htdig-3.2.0b3-082700.tar.gz.
Abel
collection.tar.gz
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
