[
https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002310#comment-13002310
]
Hoss Man commented on SOLR-2399:
--------------------------------
bq. the index.jsp is needed to gather Information about Cores [using
org.apache.solr.core.CoreContainer]
This is where the core admin handler should be useful -- you can use it to get
a list of cores and their statuses. In the example solr.xml (and by default if
no solr.xml exists) it's available at "/admin/cores" but that can be changed --
for now your JSP should be able to ask the CoreContainer for it using
getAdminPath()
(If it would be useful, we could also add a simple bit of info to the
SystemInfoRequestHandler ((/_corename_/admin/system) output to let the UI (and
external clients) know what path (if any) they can use to access the
CoreAdminHandler if all they have is the URL for a single core.)
bq. I don't want to slow this down since any effort is great! but long term, it
would be great to drop JSP completly
i agree it would be nice to show off using the velocity writer to style handler
responses in the admin ui, but i think that the general approach of using a jsp
(or servlet) as the master controller for creating a base HTML page that then
uses javascript to query all of the individual handler APIs makes a lot of
sense -- if for no other reason then that i don't think the velocity writer
could really be used on the output of the CoreAdminHandler (can it? .. what
context would it load the templates form?)
Ultimately the problem we're always going to run into is that people can
customize the paths of things in their configs - not just CoreAdminHandler but
even all of hte various core specific admin handlers.
I don't think that's something we really have to be worried about right now
(the existing admin UI certainly doesn't) but using a simple servlet/index.jsp
gives us the ability to at least start with a direct java call to answer the
question: "what is the url of the coreadmin handler?" and then from there
everything can be dynamicly driven.
If the logic in the JSP is simple enough, and the real work is done in the
javascript, then porting that JSP to velocity should ultimately be pretty
straight forward (if there is a strong desire)
> Solr Admin Interface, reworked
> ------------------------------
>
> Key: SOLR-2399
> URL: https://issues.apache.org/jira/browse/SOLR-2399
> Project: Solr
> Issue Type: Improvement
> Components: web gui
> Reporter: Stefan Matheis (steffkes)
> Priority: Minor
>
> *The idea was to create a new, fresh (and hopefully clean) Solr Admin
> Interface.* [Based on this
> [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]]
> I've quickly created a Github-Repository (Just for me, to keep track of the
> changes)
> ยป https://github.com/steffkes/solr-admin
> [This commit shows the
> differences|https://github.com/steffkes/solr-admin/commit/5f80bb0ea9deb4b94162632912fe63386f869e0d]
> between old/existing index.jsp and my new one (which is could
> copy-cut/paste'd from the existing one).
> Main Action takes place in
> [js/script.js|https://github.com/steffkes/solr-admin/blob/master/js/script.js]
> which is actually neither clean nor pretty .. just work-in-progress.
> Actually it's Work in Progress, so ... give it a try. It's developed with
> Firefox as Browser, so, for a first impression .. please don't use _things_
> like Internet Explorer or so ;o
> Jan already suggested a bunch of good things, i'm sure there are more ideas
> over there :)
--
This message is automatically generated by JIRA.
-
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]
