[
https://issues.apache.org/jira/browse/SOLR-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230656#comment-13230656
]
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 SolrInfoMBeanHandler.java 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: http://jsfiddle.net/6QeXU/3/ 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:
http://wiki.apache.org/solr/MakeSolrMoreSelfService#Request_Handler_Param_Docs)
> Admin UI: query form should have a menu to pick a request handler
> -----------------------------------------------------------------
>
> Key: SOLR-3232
> URL: https://issues.apache.org/jira/browse/SOLR-3232
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
