Gilles Detillieux (email@example.com)
Mon, 23 Aug 1999 12:33:55 -0500 (CDT)
According to Fraser Campbell:
> Love htdig, just one thing I would like to accomplish (described below) that I
> haven't figured out.
> Allow user defined (and changeable) restrict:
> The problem is that I have created a drop down menu to restrict searches based
> on site. This sets the restrict to the appropriate site but I would like the
> drop down menu to appear on the search results pages as well so that people
> could simply switch the site selected and click search to perform their search
> on another web site. Also the drop down would have to display the previously
> selected web site for the search to work right.
> If it's possible can someone send me an example config file?
This had come up on the htdig3-bugs mailing list in late July. Here is
the original message and my reply...
According to firstname.lastname@example.org:
> Full_Name: Scott Kinnane
> Version: 3.1.2
> OS: Solaris 5.6
> Submission from: ebb.prth.tensor.pgs.com (18.104.22.168)
> In trying to customise the search interface with header/footer.html
> and/or wrapper.html, I came against $(RESTRICT) as being just a value, and not
> a list.
> I had made a drop down box that listed various "restrict" areas (see
> to search sub-trees of our site - fine no problem whatsoever. Then I
> noticed I had to add the restrict feature in the header.html (and later
> to nomatch etc..). Anyway, I saw the $(RESTRICT) variable amoung the other
> variables and thought I give that a shot, except it doesn't work as a list
> :^( I tried many of the other variables (header.html is included for
> reference - forget the JS) and they all worked fine. So now all I get is the
> value I last selected. Is there any other way to include it as the list
> I created before other than by copying the html??
> Whats up with $(RESTRICT)??
You can't use the $(RESTRICT) variable in the same way as $(METHOD),
$(FORMAT) and $(SORT). This is because htsearch treats these last
three specially - it automatically sets them to <select> lists,
that include all possible choices, with the current value being the
default choice. The current values for these are passed in the variables
$(SELECTED_METHOD), $(SELECTED_FORMAT) and $(SELECTED_SORT), respectively.
The reason htsearch can build these lists is because all the choices for
them are listed in the htdig.conf attributes method_names, template_map
and sort_names, respectively. All the other input parameters are passed
to variables as a value only.
For the restrict and exclude input parameters, all htsearch ever
sees is the selected value - it doesn't know what other choices are
offered in search.html, if you define these parameters via <select>
lists in the search form. As it stands, the only way you could use
these two parameters as <select> lists in follow-up searches would be
to duplicate your lists from search.html in the follow-up search forms
in header.html, nomatch.html and syntax.html. The problem then would
be that the default value for these would be statically defined in the
lists, and not taken from the value selected in the previous search.
That is why $(RESTRICT) and $(EXCLUDE) are passed as hidden input fields
in the follow-up search forms. They could also be passed as plain text
input fields, and then the previous value would be the default, but it
could be edited by the user.
To get htsearch to work as you'd want it to would require adding another
configuration attribute that lists the choices for the restrict parameter,
as pairs of values and text labels for them, and adding code to Display.cc
to generate the select list from these. A case could be made for doing
this with almost all of the input parameters as well, but that would
get out of hand very quickly. The developers chose the input parameters
most likely to be needed as select lists in follow-up searches.
> P.S. Has anyone successfully used htdig on Cobalt products (MIPS processor /
> Linux) ... I saw other people (list archives) having the segfault problems I
> experienced. Any solutions?
Still no news on this. You and two others reported the problem with
segmentation faults on Cobalt servers. One user, Tomas Garcia Ferrari
(email@example.com) reported that it turned out to be a problem with the
egcs libraries on his machine. I wrote him back to ask for details,
but haven't received a response. I imagine the best course of action
would be to enquire if Cobalt has released updated egcs libraries, and
install them if available. Failing that, you may need to try rebuilding
them from the latest source, which may be a much more difficult/tricky
operation. Please let us know, for the archives, if you find a solution.
-- Gilles R. Detillieux E-mail: <firstname.lastname@example.org> 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 htdig mailing list, send a message to email@example.com containing the single word unsubscribe in the SUBJECT of the message.
This archive was generated by hypermail 2.0b3 on Mon Aug 23 1999 - 10:35:46 PDT