On Jun 16, 2010, at 4:51 PM, Chris Hostetter wrote:
: > +0 ... i'd prefer to keep the solr.war as lite as possible, with
as few
: > dependencies as possible -- so alowing for lazy loaded respose
writers
: > seems like a better choice to me -- but i recognize that there are
: > size/feature trade offs.
:
: There are advantages though - being able to replace the JSP pages
with
: something more malleable and potentially overridable. And it's
really not
: that heavy weight.
absolutely -- there are always trade offs, hence i am not opposed
(although to repeat an early comment from jira: i'd still rather move
towards the Admin UI being impled entirely with request handler XML
response and browser side XSLT then with velocity -- that way we can
be
*sure* that our request handlers are exposing *everything* needed to
power
the admin UI, so it's all available programaticly as well)
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 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 can live in a JAR in <solr-
home>/lib (or anywhere thanks to your <lib> stuff).
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)
But moving forward, since you're not objecting and no one else has,
here's a JIRA issue with svn mv commands and a patch file that moves
VrW to core along with a nice new search UI, full featured with
faceting, highlighting, spell checking, and sticky enable/disable
debug mode. Let me know what you think. I'll commit in a day or so.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
