lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler
Date Thu, 15 Mar 2012 22:38:37 GMT


Hoss Man commented on SOLR-3232:

bq. Anyway, I'll let it go, and just roll my eyes at all the hacks and duplication that building
an entirely Ajax UI using pure JSON responses entails.

I've said it before and i'll say it again: the single most important reason why i think the
javascript based Admin UI is a great idea is becuase it *forces* us to make sure all of the
info needed to build the admin UI is available via HTTP using request handlers and what no
-- ensuring that we think about how other clients can programmatically access the same information.
the old JSPs and the velocity engine generated pages had too much direct access to internals,
making it too easy to overlook when external clients didn't have access to useful data.

bq. How about adds a simple "searchHandler" attribute with true/false?

I think it would be just as easy and far more generally useful add a request param to SolrInfoMBeanHandler
that would let you filter the objects by what class's they are an instance of just like it
can filter by "cat" and "key" right now (ie: "/admin/mbeans?class=solr.SearchHandler").


As far as this issue in general: i think it's a good idea to add a pulldown to make it more
friendly to folks and easier to use in the common case, and populating the pulldown with all
the instances of SerachHandler makes a lot of sense, but we should try to use some UI element
that will allows people to type in their own handler name if they want (ie:
but i'm sure thers a clearner more efficient way to do it) so we don't anoy people who have
their own custom RequestHandlers that don't subclass SerachHandler, or want to use things
like MoreLikeThisHandler, etc...)

(Longer term, it would be to make querying the AdminHandler return all sorts of useful introspection
info about what is currently running to drive the UI screen generation, with optional config
on the handler to override things maybe i don't wnat to advertise some search handler instance?)
along the lines of this brainstorming doc i write a long, long time ago:
> Admin UI: query form should have a menu to pick a request handler
> -----------------------------------------------------------------
>                 Key: SOLR-3232
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: web gui
>            Reporter: David Smiley
>            Assignee: Stefan Matheis (steffkes)
>             Fix For: 4.0
>         Attachments: SOLR-3232.patch
> The query form in the admin UI could use an improvement regarding how the request handler
is chosen; presently all there is is a text input for 'qt'.  The first choice to make in the
form above the query should really be the request handler since it actually handles the request
before any other parameters do anything.  It'd be great if it was a dynamically driven menu
defaulting to "/select".  Similar to how the DIH page finds DIH request handlers, this page
could find the request handlers with a class of "SearchHandler".  Their names would be added
to a list, and if the name didn't start with a '/' then it would be prefixed with '/select?qt='.
> I did something similar (without the menu) to the old 3x UI in a patch to SOLR-3161 which
will hopefully get committed.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message