You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erik Hatcher (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/03/16 02:20:37 UTC
[jira] [Issue Comment Edited] (SOLR-3232) Admin UI: query form
should have a menu to pick a request handler
[ https://issues.apache.org/jira/browse/SOLR-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230801#comment-13230801 ]
Erik Hatcher edited comment on SOLR-3232 at 3/16/12 1:19 AM:
-------------------------------------------------------------
bq. 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.
My reply to that is that with VrW you can give the client basically whatever it needs in this Ajax-world, by generating _exactly_ what the client needs (either an HTML snippet to drop in or text suggestions as in /browse; HTML snippets can include setting a JavaScript variable looking at internals, for example). Don't get me wrong, I understand fully the desire and need for useful data being sent via the general response writer infrastructure, and not fighting progress on that, just the instant reaction to add something to the response that in this case is likely not mapping to what the internal routing logic is doing and also being a bit gratuitous to have it all in JSON when a decent way to get the data needed for this individual use case is already there. Simply being pragmatic, adding less code.
And I'm particularly +1 on making "querying the AdminHandler return all sorts of useful introspection info about what is currently running to drive the UI screen generation". I've been a big fan of the request handler param introspectability for sure. Anyone seen how Ant tasks are built under the covers? I'm thinking like that. We introspected Ant's own Java API to generate the task reference in "Java Development with Ant", complete with parameter and nested element names, data types, and descriptions (even enumerated values).
was (Author: ehatcher):
bq. 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.
My reply to that is that with VrW you can give the client basically whatever it needs in this Ajax-world, by generating _exactly_ what the client needs (either an HTML snippet to drop in or text suggestions as in /browse; HTML snippets can include setting a JavaScript variable looking at internals, for example). Don't get me wrong, I understand fully the desire and need for useful data being sent via the general response writer infrastructure, and not fighting progress on that, just the instant reaction to add something to the response that in this case is likely not mapping to what the internal routing logic is doing and also being a bit gratuitous to have it all in JSON when a decent way to get the data needed for this individual use case is already there. Simply being pragmatic, adding less code.
And I'm particularly +1 on making "querying the AdminHandler return all sorts of useful introspection info about what is currently running to drive the UI screen generation". I've been a big fan of the request handler param introspectability for sure. Anyone seen how Ant tasks are built under the covers? I'm thinking like that. We used introspected Ant's own Java API to generate the task reference in "Java Development with Ant", complete with parameter and nested element names, data types, and descriptions (even enumerated values).
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org