Please also consider the MIT Simile-Widgets "Exhibit" toolkit, which can be used to great leverage in building search tools for Xwiki: http://code4lib.org/node/154 <-- Exhibit+Solr/Flare
I've posted about Exhibit integration w/ Xwiki in the past. http://www.mail-archive.com/[email protected]/msg09435.html . (Introduction to Exhibit: http://www.ibm.com/developerworks/web/library/wa-realweb6/ or http://www.linux.com/archive/feature/118440 ) One of the big advantages is that Exhibit took care of a lot of the "hard work" so you can concentrate more on application specifics and how exactly you want it to look. This includes portability that comes from wide use and application of Exhibit 1.0->2.+ - mature and stableand opensource. It also includes some of the tedious details such as proper implementation of "forward" and "back" in the browser -- it doesn't navigate between pages, but automatically remembers to move forward or back in your search refinements (assuming you use exhibit for a faceted search UI). I'm beginning to think that it's more reasonable to mostly avoid HTML as anything other than the language that defines templates and overall layout, and then have all the interior "UI Widgetry" created dynamically in JS. The server ends up setting up the appropriate "page-templates" (HTML) initially, and then sends over a blob of JSON to describe the page's initial state/data/etc; and the abstract data is rendered into a UI via javascript. This level of abstraction, as implemented by Exhibit 2.0, has the advantage of enabling easier translation of a UI for different displays, e.g. mobile/iphone versus desktop/web. I believe there is an Iphone version of exhibit available or being worked on at simile.MIT.edu . As such, Exhibit is a very interesting "UIMS" -- user interface management system -- with unusual flexibility: something I've been wanting for a very long time http://nielsmayer.com/L18623-5228TMP.pdf :-) Exhibit's advantage in a search engine is that the engine would just return a UI-independent blob of structured data, and you could have multiple different ways of displaying this search data in a framework like exhibit. Alphabetically, with thumbnails, on a timeline, on a histogram, scatterplot, etc: see examples at http://www.simile-widgets.org/exhibit/ to get an idea of the kinds of displays possible. Then find the "see JSON data" to get an idea of the abstract data driving the application. For example this JSON: http://www.simile-widgets.org/exhibit/examples/nobelists/nobelists.jsproduces this UI via Exhibit: http://www.simile-widgets.org/exhibit/examples/nobelists/nobelists.html Niels http://nielsmayer.com On Wed, Jun 17, 2009 at 1:40 AM, Vincent Massol <[email protected]> wrote: > Hi, > > I think the new search results page (the main search one not the > lucene one) has some limitations that could be improved: > - it doesn't scale with large number of documents (if you do a search > that returns a lot of documents) > - it doesn't allow refining your search easily > - the information presented take up more vertical space than needed > (currently 3 lines instead of one) and thus less results can be > presented > - it could be reused by other pages which require listing documents > such as the SpaceIndex which lists all pages in a given space. It's > actually currently reused but as a consequence the SpaceIndex page > isn't nice at all and doesn't scale. > > Would it make sense to: > - have a livetable > - display all docs by default when you arrive on the search page (ie > no filter set) > - make the current search field a field bound to the livetable and > that filters that table when text is typed inside > - remove the need for the spaces combo box since it would be a filter > field in the livetable already > - same for the wiki field > > Pros: > - all the limitations listed above are resolved > - the search becomes live (that's a + compared to other solutions > since I haven't seen other apps do this) > - it unifies the way we use livetable across XE > - if we do this we could also modify the AllDocs page to have the > global search field. Basically wherever we display documents we could > also include this search field. > > Main Question: > - would the live search be costly? With Lucene search probably not, > with the DB search, it could (for ex if document content isn't indexed). > > WDYT? > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
