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

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

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