[
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: [email protected]
For additional commands, e-mail: [email protected]
