Moved from SearchAllTWikiWebs

---

A simple and powerful, but somewhat technical solution is to introduce a new variable in TWikiPreferences, lets say %WIKIWEBSELECTOR% , that contains the <select>...<select> list box with all webs that should be visible. Here is an example (The form is added for demonstration only, the actual variable would only define the <select>...<select> part) :

Main Codev Know Test

This form could be used on the view template to jump to a web (instead of the { Main | Codev ... } list. (The current view script needs to be extended to understand a "web=" parameter)

TWiki could implicitely create yet another variable %WIKIWEBSEARCHSELECTOR% , it is the %WIKIWEBSELECTOR% variable with a <option value="*" >(all webs)</option> added after <select> . The current web would be selected. This selector would be the optional selector for the search form:

(all webs) Main Codev Know Test

The downside of this design is that the user needs to define the webs twice in TWikiPreferences. This would be OK with me. Opinions?

-- PeterThoeny -- Apr 2000

part one We seem to be proliferating webs here at DrKW - it seems that everyone who has a project wants their own web. Short of going to hierarchical webs this variable is invaluable as the number of WebSearch templates proliferates. Did anyone do this yet? If not I'll do it tomorrow and input to CVS via JohnTalintyre.

part two Have now found the getAllWebs function in Store.pm - will add a wikivar to handleCommonTags in TWiki.pm - %WIKIWEBSEARCHSELECTOR% that gets the list and renders in drop box HTML as described above unless anyone objects. We could put into DefaultPlugin? .pm - but it seems like this would be useful in the TWiki core.

part three It seems that just rendering

<option>...</option>

is most flexible. This allows the template to have any name for the selection and any other components such as the (all webs) option.

-- SteveRoe - 30 May 2001

TopicClassification:

FeatureEnhancementRequest