At 09:09 AM 08/06/02 -0700, Thomas M. Parris wrote:
>I want a form that allows multiple search strings (one for each searchable
>metatag) with an implicit AND between the searches. For example:
>Title: [fill in the blank ]
>Author: [fill in the blank ]
>Subject: [pull down menu ]
>Year: [fill in the blank ]
>The current configuration options seem to only allow for a single fill in
>the blank field (via metanames) and a single field defined on the content of
>a metatag (via select_by_meta). However, the select_by_meta method is
>implemented as a limit (i.e., it does not stand alone as a search, it
>requires that the search field have something in it).
Right, there's no way to do that just with adjusting the configuration.
>I'm guessing that you will tell me to hack away at build_query and
>TemplateDefault::get_meta_name_limits to do what I want. But, I wanted to
>make sure I wasn't overlooking the obvious. If there is an easy way to do
>this, stop now and tell me. Otherwise, read further to see how I sould hack
That poor old script has been hacked at quite a few times now, which is why
there's an odd collection of configuration settings. It's an example of
how to make a reasonably easy task complicated. ;)
If you have good perl skills you might consider creating a new script
instead of hacking away at swish.cgi. My guess is you could end up with
something much cleaner if the script was rewritten in a stronger MVC
architecture. The current script tries to do too much in a configuration
Create a View with a templating system (like TT2), and write a simple
Controller to process the CGI/mod_perl request and select the View. And
then use something like (the outdated) Swish::Fork module on CPAN for the
model (or write your own from code extracted from swish.cgi). The config
file should just have paths and maybe template names.
In other words, have one module that displays the form, another that knows
how to convert the form into a request to swish, and then a module to
process that request (i.e. run swish and return a list of results that's
formatted by a template).
It's gets hard (and ugly) to make one script work for every possible setup.
On the other hand...
>If I was to hack away at these modules, I would probably build a loop over
>query variables (e.g., query1 ... queryn) and make the metanames
>configuration option an element of a searchfield structure.
I might use "query_$metaname".
>searchfield, I would also provide options similar to that for
Then as an optional parameter a callback function in the config which would
allow parameter validation.
>Finally, I would provide an option for how the searches
>should be connected. For example:
>searchconnector => 'AND', # can be 'AND', 'OR', 'USER' (where 'USER' put out
>a pulldown form element).
To complicate things, you might want to provide a selection of how to
combined the query. Here's another example: http://lii.org/advanced
>Would there be interest in incorporating such a hack into the main
Probably. Logic would also need to be added to each of the Template::*
modules to support this.
>p.s. I would be great if there were a swish method to get the list of
>database values for a given metaname. This would simplify the process of
>specifying radio_group, checkbox_group, and popup_menu items.
Well, there's always a way. It would be a bit tricky to automate.
swish.cgi would want to cache the values instead of fetching on each
request, of course.
If a metaname is also a propertyname you can just do a search like:
./swish-e -w not dkdkdkslajksjflsdj -x '<$propertyname>\n'
Or, you can do
./swish-e -T index_words_meta
and dump out the entire index and parse out what you need.
Received on Tue Aug 6 18:42:49 2002