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 (Commented) (JIRA)" <ji...@apache.org> on 2012/03/12 14:20:39 UTC
[jira] [Commented] (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=13227503#comment-13227503 ]
Erik Hatcher commented on SOLR-3232:
------------------------------------
Stefan - /browse and search *are* SearchHandler's. Even with SOLR-3161, these are legitimate request handlers to issue search requests to.
In your page you have this:
{code}
handlers[key]['class'] === 'org.apache.solr.handler.component.SearchHandler'
{code}
That simply isn't sufficient for determining a SearchHandler though.... and this points out more about why doing this sort of stuff client-side is brittle. You really need a Java-side "instanceof" check to be sure if a request handler is *subclassed* from SearchHandler, not just directly but perhaps indirectly (like StandardRequestHandler).
Again, I'll just toss this out there because I feel strongly about HTML-inside-JavaScript-strings and everything coming from Ajax calls this way - the VelocityResponseWriter allows for very simple server-side templating and internal access to these sorts of things. It'd be easy to generate a drop-down box (or JavaScript string array, whatever you'd like) using Solr's internal state and instanceof kinda checks. An example from your patch on this is:
Also, in light of SOLR-3161, it's risky to add checks for acceptable request handlers anywhere in a secondary manner as the logic may not match. It's important to ensure that what's presented matches what is truly available, and this be done using common server-side logic.
> 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