lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: velocity response writer breaks portability
Date Thu, 17 Jun 2010 17:07:45 GMT

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

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

: And besides, poking a stick in one's eye is a fair bit more pleasant than
: writing/maintaining XSLT.  ick!  (and yes, I've done so professionally for a
: couple of jobs so I'm speaking from my experiences)

no disagreement -- but i actually find that to be a plus from an "ensure 
data accessibility" standpoint: if you can craft and XSLT for your 
XML that displays the data effectively w/o hanging yourself first, then 
you definitely have an XML structure that *anybody* can use effectively.

but all of this is just my opinion, and it's been my opinion for a long 
time, but i haven't gotten arround to doing anything about it -- you're 
actively pursuing a solution that's differnet then mine but still 10x 
better then what we've got, so more power to you.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message