Can you elaborate on the use case for why you need the raw response
like that?
I vaguely get it, but want to really understand the need here.
I'm weary of the EmbeddedSolrServer usage in there, as I want to
distill the VrW stuff to be able to use SolrJ's API rather than assume
embedded Solr. This way VrW can be separated from core Solr to
another "tier" and template on remote Solr responses. Thoughts on how
this feature might play out in that scenario?
Erik
On Nov 17, 2008, at 1:09 PM, Matthias Epheser wrote:
Erik Hatcher schrieb:
On Nov 17, 2008, at 11:45 AM, Matthias Epheser wrote:
Just noticed that VelocityResponeWriter in trunk is very reduced
to my last
patch from 2008-07-25.
Right, that was intentional for my own simplicity's sake...
The crucial difference is the missing translation into a solrj
response by specifying the vl.response parameter. This was
intended to make template creation more handy, cause the
queryResponse is much nicer to navigate.
If this conversion is to specific and shouldn't be in
VelocityResponseWriter, would it be a problem to create a subclass
inside contrib/javascript?
I need to understand it a bit more, but no subclass is necessary...
we'll patch it into contrib/velocity's VrW like you had it before.
The key part is to pass a parameter like vl.response=QueryResponse,
so the transformation works like that:
object =
request.getCore().getResourceLoader().newInstance(className,
"client.solrj.response.");
solrResponse.setResponse(new
EmbeddedSolrServer(request.getCore()).getParsedResponse(request,
response));
This was done based on api changes from Ryan to generalize the
second setResponse part. In the etmplate , there is access to the
created response, as well as to the "rawResponse".
I'll try to add the least necessary stuff to current vrw, test ist
against solrjs and post a patch to jira.
matthias
Erik
