Which mostly are wrong in curriki search according to my opinion: - they don't cache properly- they add a step into the history at entry (so back out of search doesn't work)
Curriki search uses, as far as I know, ExtJS. If such a JS artifact is used, it should be better than that.
paul Le 17-juin-09 à 12:22, Ludovic Dubost a écrit :
Yes, I second that. Now there are JS practices which can make it work, by updating the history of the browser in JS so that back works. Ludovic Paul Libbrecht a écrit :I have one single major con: a search result should be a concrete URL one that works well with the back button. I much dislike Curriki search which is doing something such and ours doesn't. (try the search boxes on http://i2geo.net (ours), and Curriki http://www.curriki.org/ ) The Lucene search can be enhanced to be more performant for this I think (lowering the amount of stored fields), it is known to be able to handle 1000-2000 requests a second. paul Le 17-juin-09 à 10:40, Vincent Massol a écrit :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 searchthat 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 filterfield 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 theglobal search field. Basically wherever we display documents we couldalso 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-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
