lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler
Date Fri, 16 Mar 2012 01:20:37 GMT

    [ 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


Mime
View raw message