: 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. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
