[ 
http://issues.apache.org/jira/browse/SOLR-58?page=comments#action_12448568 ] 
            
Hoss Man commented on SOLR-58:
------------------------------

A few comments/questions in no particular order...

0) in general, i've found it's difficult to know how hard some XML will be to 
style, untill you've tried styling it :(

1) the assumption is that these will include xsl-stylesheet headers list 
stats/registry do right now and let teh browser apply them right?

2) Within the outermost <solr> tag, it would probably be good to have another 
wrapper tag specific to each of the pages .. it might make reusing a single (or 
a small number of) XSL file(s) for multiple pages easier.

3) I think for analysis.jsp you're going to want a <form> block containing info 
about the options used and a <results> block containing what you've got right 
now ... otherwise it's going to be hard for an XSLT to recreate the form with 
the current state filled in (as i recall: there are ways of getting the URI of 
the current document in XSLT, and parsing out it's query params, but they have 
issues ... and they don't work if someone attempts to save the file locally to 
review later)

4) it would probably make more sense to group the <token>s as children of the 
<factorry>s when verbose is turned on ... acctaully it would probably make 
sense to group them under the <factory> even if verbose isn't on....

5) as long as we are outputing structured XML, we should render the 
factory.getArgs() as individual key/val pairs instead of just a string, maybe 
something like...

<factory class="org.apache.solr.analysis.WordDelimiterFilterFactory">
   <args>
      <arg name="catenateWords">1</arg>
      <arg name="catenateNumbers">1</arg>
   </args>
  <tokens>
     <token type="word" pos="1" start="0" end="6">Search</token>
     <token type="word" pos="2" start="7" end="12">Stuff</token>
     <token type="word" pos="2" start="0" end="12">SearchStuff</token
  </tokens>
</factory>

...or if verbose is off...

<factory>
  <tokens>
     <token type="word" pos="1" start="0" end="6">Search</token>
     <token type="word" pos="2" start="7" end="12">Stuff</token>
     <token type="word" pos="2" start="0" end="12">SearchStuff</token
  </tokens>
</factory>

6) converting action.jsp to XML might actually make sense if you want to 
programatically hit it to change the logging level and test that the operation 
succeeded (right now you'd have to parse the HTML)

7) ping's utilitiy for monitoring systems like nagios and load balancers is 
that it's trivial to check if the port is functioning just by checking the HTTP 
status code (where the definition of functioning is defined by a query in the 
solrconfig) ... it *must* have a genuine HTTP status code != 200 if there is a 
failure, returning an HTTP status code of 200 with a response body that says 
<status="500">...</status> just makes everything more complicated.

...either it shouldn't be converted, or it should manually set the reponse 
status to 500 before outputing the XML representation of the exception  
(incidently: it will need to be XML escaped too)



> Change Admin components to return XML like the rest of the system
> -----------------------------------------------------------------
>
>                 Key: SOLR-58
>                 URL: http://issues.apache.org/jira/browse/SOLR-58
>             Project: Solr
>          Issue Type: New Feature
>          Components: web gui
>            Reporter: Otis Gospodnetic
>         Assigned To: Otis Gospodnetic
>            Priority: Minor
>         Attachments: analysis-xml-out.txt, analysis-xml.jsp, logging-xml.jsp, 
> ping-xml-out.txt, ping-xml.jsp, threaddump-xml-out.txt, threaddump-xml.jsp
>
>
> I need to expose the admin functionality to an external application.  I think 
> returning admin data as XML may be a good and simple first step towards that.
> To do that I think I'll mostly need to modify JSPs (but I haven't had a good 
> look at Admin GUI yet).  From what I saw a few weeks ago when I briefly 
> looked at this, no Java code will need to be modified.  If you have concrete 
> ideas about how this should be done, please comment before I start next week 
> (week of October 23rd 2006).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to