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/devs@xwiki.org/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.jsproduc…
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 <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs