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-3162) Continue work on new admin UI
Date Tue, 28 Feb 2012 18:39:46 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218444#comment-13218444
] 

Erik Hatcher edited comment on SOLR-3162 at 2/28/12 6:39 PM:
-------------------------------------------------------------

Quoting from a comment above:

bq. ... Additionally we would need the functionality as a handler/servlet-thingy ...

This is where the, tada, VelocityResponseWriter could really help here.  Rather than raw *data*
having to come from Ajax calls, through a Velocity template you can get at pretty much _anything_
from the SolrCore and configuration, and then use that to generate a response (even, say,
an "x = '$whatever'" kinda variable into JavaScript.  For example:

{code}
never304 = $request.core.solrConfig.httpCachingConfig.never304
{code}

You could get this using an out of the box request like this: http://localhost:8983/solr/select?q=*:*&wt=velocity&v.template=foo&v.template.foo=never304%20=%20$request.core.solrConfig.httpCachingConfig.never304
(though of course I'd recommend templates be created from this under conf/velocity rather
than passed in via the request).  The point is, everything can be gathered when you're "inside"
Solr, but requires explicit exposing of these inner details to make the data available cleanly
for this Ajax-the-data-generate-UI-in-JavaScript approach.


                
      was (Author: ehatcher):
    Quoting from a comment above:

bq. ... Additionally we would need the functionality as a handler/servlet-thingy ...

This is where the, tada, VelocityResponseWriter could really help here.  Rather than raw *data*
having to come from Ajax calls, through a Velocity template you can get at pretty much _anything_
from the SolrCore and configuration, and then use that to generate a response (even, say,
an "x = '$whatever'" kinda variable into JavaScript.  For example:

{code}
never304 = $request.core.solrConfig.httpCachingConfig.never304
{code}

You could get this using an out of the box request like this: http://localhost:8983/solr/select?wt=velocity&v.template=foo&v.template.foo=never304%20=%20$request.core.solrConfig.httpCachingConfig.never304
(though of course I'd recommend templates be created from this under conf/velocity rather
than passed in via the request).  The point is, everything can be gathered when you're "inside"
Solr, but requires explicit exposing of these inner details to make the data available cleanly
for this Ajax-the-data-generate-UI-in-JavaScript approach.


                  
> Continue work on new admin UI
> -----------------------------
>
>                 Key: SOLR-3162
>                 URL: https://issues.apache.org/jira/browse/SOLR-3162
>             Project: Solr
>          Issue Type: Improvement
>          Components: Schema and Analysis
>    Affects Versions: 4.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-3162.patch, SOLR-3162.patch
>
>
> There have been more improvements to how the new UI works, but the current open bugs
are getting hard to keep straight. This is the new catch-all JIRA for continued improvements.

--
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