According to Gabriele Bartolini:
> Ciao Gilles and Geoff,
>
> I have to ask you one thing about ht://Dig 3.1.5 . Maybe you can give
> me some useful news. Yesterday I had to configure (after a lot of time) a
> new template for ht://Dig on the website where I work. This small website
> belongs to the whole website, and already belongs to the daily updated
> ht://Dig database. So ... I just have to share the database and create a
> new template for this second website, in order to fake a new separate
> search engine, right?
>
> I do this very easily by setting up a new HTML form, with a config
> value pointing to the custimised one, and a restrict value in order to
> limit the search domain. That's here where I want to act. Indeed I was sure
> that there was a configuration attribute for restrict, but I was not able
> to find it. And so I gave a look at the code, but the only restrict command
> allowed is as CGI variable.
Yes, that's correct. It's the same situation in both the 3.1.x and 3.2.x
code bases. This is one of the CGI variables that needs to be fixed, as
mentioned in the 3.2 development code's STATUS file:
* Not all htsearch input parameters are handled properly: PR#648. Use a
consistant mapping of input -> config -> template for all inputs where
it makes sense to do so (everything but "config" and "words"?).
The correct handling for these should be to map the input parameter,
if given, to a config attribute (overriding any provided in the config
file), and finally mapping the config attribute to a template variable,
for passing the attribute value to follow-up search forms. Also, in
Display::createURL() it should pass any existing input parameters into
the new query string.
Most CGI input parameters are actually handled this way, but a few aren't
(most notably restrict and exclude). The handling of allow_in_form models
the proper handling. I've been thinking that all the other "hard-coded"
mappings of input parameter to config attribute should be put into a table
and handled in a similar fashion to allow_in_form (taking into account the
fact that not all mappings use the same name throughout for input, config
and template, which is unfortunate but probably too late to change).
> I guess that by adding a restrict value into the configuration file
> would be a very useful feature, wouldn't it?
Absolutely. Same for exclude and any others that aren't handled
consistently. Fixing all of them, and doing it properly, is not a huge
job, but more than I have time for right now. If you want it, the
job is yours. I can review your changes if you like. Remember that
both 3.1 and 3.2 will need the change. If what I suggested above is
too complex, it may be easy enough to just change the few inputs that
are not handled correctly now, to use them the way other inputs like
"keywords" are handled.
> Please let me know if you agree with me and let me know if I was wrong
> and there is already something for this. If not, please tell me if it's
> possible for me to modify the 3.1.x branch and add this (if it is still
> possible!). However if this is the path I have to walk, can you please
> summarize to me the steps I have to perform in order to check out this
> branch? Indeed ... I can't see any CVS tree for this version on
> sourceforge ...
>
> Well, waiting for an answer, I wish you a wonderful weekend!
>
> Ciao
> -Gabriele
As far as I know, it's still possible. It's the htdig-3-1-x branch of the
htdig CVS tree, but you should make parallel changes to the htdig-3-2-x
branch as well.
--
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
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/htdig-dev
