Feature Proposal: recode the search cgi to show view/System/WebSearch
Motivation
http://foswiki.org/bin/search is broken, and has been for longer than we've existed - try it out.
if you know the right parameters then you can get it to do something - ie
http://foswiki.org/bin/search/System?search=test
but really, what functionality does that give me that
http://foswiki.org/System/WebSearch?search=test doesn't do better?
Description and Documentation
I'd like to change the
search
cgi to call the
view
cgi code, showing either SYSTEMWEB's
WebSearch, or if a web is specified in the url, that web's
WebSearch. (essentially an internal redirect)
additionally, I can
hopefully remove a couple of lines of code from Search.pm, and remove the search.tmpl file.
I
think that removing this will allow us to remove any code for the non-=$inline= case
# Write log entry
# FIXME: Move log entry further down to log actual webs searched
if ( !$inline ) {
my $t = join( ' ', @webs );
$session->logEvent( 'search', $t, $searchString );
}
This may affect
NatSkin or some other skin , but I'm not sure.
Examples
Impact
Implementation
--
Contributors: SvenDowideit - 09 Mar 2010
Discussion
Do you propose to
remove the
search
cgi and/or
search.tmpl
? The
search.xxxskin.tmpl
files have a quite specific function though, independent of the cgi.
Can you detail where and when
search.tmpl
is used in the core?
How can customizations made via
search.xxxskin.tmpl
be done otherwise?
There aren't hardly any links to the
search
cgi. Users come via WebSearch, next to zero via a
search
cgi.
--
MichaelDaum - 09 Mar 2010
No, I am
not proposing to remove the search cgi, just to make it call the same code as
view/web/WebSearch
so that there is one fewer code path for us to fail to test.
most of the function of
search.tmpl
is to load
view.tmpl
to expand it into a complete html result - by making search cgi an internal redirect to the
WebSearch topic, we can simplify this, and produce a backward compatible output - catering for any old-timers that actually use search cgi.
Additionally, there is a mass of redundancy and confusion producing cruft -
searchformat.xxxskin.tmpl
seems to be the main tmpl file used for inline rendering, unless a
format
is not specified..
This really takes me to the next feature proposal -
SimplifySearchTemplates - I want to separate these so that we don't need to hold up the simple things to discuss the more complex ones.
To summarize - this proposal is specifically about making
search
cgi an internal redirect to
view/web/WebSearch
and taking advantage of this to remove any un-used code.
It may be interesting to know if the redirect should be configurable - so that you could use it to call SolrPlugin, or even to a completely external searcher like a google appliance.
--
SvenDowideit - 09 Mar 2010
The core of
search.tmpl
is this
TMPL:DEF{"content"} SPLIT TMPL:P{"searched"} SPLI TMPL:P{"header"} REPEAT TMPL:P{"result"] REPEAT SPLIT TMPL:P{"count"} SPLIT TMPL:END
... which is aweful, to be polite. So
SimplifySearchTemplates is
very welcome as it is not hard to be better than that. There are other templates along this REPEAT/SPLIT pattern
which are of similar beauty.
--
MichaelDaum - 10 Mar 2010
Let me try and list how
I believe the situation is with search cgi.
- It is broken - if people use it they must be living with bugs
- Noone that I can recall have reported bugs against the search binary
- In TML apps people use %SEARCH. It is not natural to use search binary for this.
- Our own use goes back to Cairo or before and have long since been implemented by normal %SEARCH in WebSearch
- Sven's proposal makes URLs with search still work for the few that may have used it (Sven please confirm)
- Main issue seems to be related to possible impact on skins.
Unless I have misunderstood the whole thing, this proposal is not that bad.
--
KennethLavrsen - 12 Mar 2010
yup, your list is right - I think its a useless, convoluted legacy of a bad idea, which is making other work on Search.pm difficult, while adding zero value.
and i confirm, it makes URLs with search still work for the few that may have used it.
--
SvenDowideit - 12 Mar 2010
14 days have passed, and I've riped out the code
--
SvenDowideit - 24 Mar 2010