On 1/12/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
What the user-interface needs is a way to ask Solr for terms that begin with a specified prefix, as the user types.
Sounds like this stuff could/should be extensions to the current facet.field facet.field=year&f.year.facet.prefix=186 or facet.field=year,f.year.facet.terms=186* or facet.terms=year:186* #the latter two forms could relatively easily allow for anything that could be converted #to a TermEnum, so all wildcards could be handled. Just parse with the queryparser and # check what type of query comes out? With the last form, facet.terms=year:* is equivalent to facet.field=year supporting start/end terms: facet.field=year&f.year.facet.startterm=1860&f.year.facet.endterm=1899
Paging via start/ rows is necessary,
Hmmm, really? Not too hard I guess, but I'd be interested in how you use it.
and also sorting by frequency given some specified constraints.
Faceting code does this when given a limit... did you mean anything else?
As for Hoss's suggestion of a Stats handler - I still hold the opinion that all of the admin JSPs really ought to be first class request handlers that go through the whole ResponseWriter stuff, so I can get all of that great capability in Ruby format instead of XML. As it is, to build a Ruby API to Solr and provide access to the stats, there has to be two different parsing mechanisms. I know he meant index stats, not Solr admin stats, but it reminded me of the XML pain I'm going to feel in solrb to add Solr stats :)
Specific stats are subject to change... will you be treating them generically? I think the path of least resistance is to temporarily forget about the admin pages, add an admin handler, and tailor the output to programmatic parsing. Decoupling from the admin GUI means it doesn't become a requirement to port the current stylesheets and get everything working again. The admin pages could be moved over later when someone who has the time, inclination and gui skills to do so. -Yonik
