On Jun 17, 2010, at 1:07 PM, Chris Hostetter wrote:
: I'm confused by that comment about XSLT. How would using XSLT
client-side be
: any more sure that the handlers are exposing everything? All ya
gotta do
: when using VrW is flip to wt=xml and you can then see everything
used to
I'm horribly un-informed about Velocity and the VrW, but my
recollection
from a previous discussion about this idea (i thought it was on
list, but
it might have been an offline discussion at apachecon or a meetup) was
that since the Velocity engine runs in the ServletContext, a template
could use direct object refrences to access data that wouldn't be
available to remote clients parsing the xml or json output -- ie: a
well
intentioned but lazily written patch might get committed that uses a
refrence to the SolrCore to get access to some data directly in a
velocity template, rather then the more general solution of updating
hte
appropriate request handler to add that data to the
SolrQueryResponse so
that all response writers return that data.
You're sorta right. It doesn't run in the ServletContext, though. It
simply passes the Solr request and response objects into a Velocity
context (meaning these objects are available to do whatever you want
with). And there are some other "tools" that get put in the context
that allow HTML, URL, and other escaping, number formatting, etc.
Yes, the templates could reach out into any of these objects (but no
others) and drill down to get information that wouldn't be presented
in an XML response. I don't see that as a negative though. But
certainly your point about it being able to present more than what XML
could is valid.
: generate the view. The same HTML would come out either way. With
XSLT, a
: plugin couldn't bring in it's own .xsl file for the client to use
(at least
: not currently, no way to serve a file from a JAR). With
Velocity, .vm files
i'm pretty sure that ResourceLoader will fall back to the
ClassLoader when
trying to access files not found in the conf directory -- which means
plugins should be able to include XSLT files in their jars, and
stylesheet
urls like "/admin/file?custom-plugin-a.xsl" would work (we just need
to
fix some foolish assumptions in the XmlResponseWriter's usage of the
stylesheet param so it's more generally useful)
I don't think ShowFileRequestHandler does this. It uses the File
object and such. I'd be surprised if it could, and it really should
NOT be able to do that - that would allow one to serve up any files on
the classpath, .class, etc. I'd consider that a major hole. The
Velocity stuff doesn't work that way. Templates are not servable to
the client from the classpath. But /admin/file could serve up *files*
under /conf/velocity though - which is as designed and with a way to
shut them off via excludes if desired.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
