Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 17 Jun 2010 10:07:45 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: dev@lucene.apache.org
Subject: Re: velocity response writer breaks portability
In-Reply-To: <8850A2A2-00E6-4FF7-B180-A71EFEBABCDA@gmail.com>
Message-ID: <alpine.DEB.1.10.1006170952510.4842@radix.cryptio.net>
References: <27C7F30D-EA8F-4F9F-85F6-8E048FC35C0C@gmail.com>
 <alpine.DEB.1.10.1006161319420.392@radix.cryptio.net>
 <780F6E34-D6D9-40A9-8982-60F341B59C8D@gmail.com>
 <alpine.DEB.1.10.1006161348561.392@radix.cryptio.net>
 <8850A2A2-00E6-4FF7-B180-A71EFEBABCDA@gmail.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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