Erik Hatcher schrieb:
I'm getting back into the SolrJS/Velocity world and just wanted to toss
out some thoughts:
On trunk, the Solr demo works by just opening
contrib/javascript/example/testClientside.html - not bad! :)
It is, however, making two requests to render the page:
Nov 22, 2008 4:39:06 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={wt=json&rows=20&start=0&_=1227346746973&json.wrf=jsonp1227346081952&q=*:*&jsoncallback=jsonp1227346081952}
hits=28 status=0 QTime=1
Nov 22, 2008 4:39:06 AM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select
params={wt=json&rows=0&start=0&facet=true&_=1227346746974&facet.field=cat&json.wrf=jsonp1227346081953&q=*:*&jsoncallback=jsonp1227346081953}
hits=28 status=0 QTime=1
While I'm sure this is complicated stuff, it would be ideal if the
SolrJS "manager" could somehow be involved to minimize the calls made to
the server. Each widget will want to somehow register itself and add
any additional parameters and be alerted when data changes somehow too,
it seems. Or a widget might be standalone and require it's own calls to
Solr as well, independently of grouped widgets that interact together.
I'm new to the guts of SolrJS though, so maybe it already is ahead of me
here?
You are right, currently every widget requests the data itself. As all of this
stuff happens in the doRequest method, it may be possible to provide another or
switchable implementation in the Manager. As the needs will differ between the
use cases (widgets using different request handlers, grouping of widgets,..),
the modularity of solrjs should provide components that can be put together. We
may extract it to an abstract RequestStrategy and create several implementations.
---
I mentioned this early on, but I guess it never got factored into
SolrJS, the URL to send to Solr needs to be considered these three
separate pieces... base URL (http://localhost:8983/solr), request
handler path (/select, for example), and parameters
(?q=*:*&facet=true&facet.field=cat). Right now SolrJS considers the
base URL and request handler path as one unit:
solrjsManager = new
$sj.solrjs.Manager({solrUrl:"http://localhost:8983/solr/select"});
We'll want the base URL to be used with various request handlers. For
example, I have one to generate SIMILE Timeline XML like this:
<requestHandler name="/timeline.xml" class="solr.SearchHandler"
startup="lazy">
<lst name="defaults">
<str name="defType">dismax</str>
<str name="q.alt">*:*</str>
<str name="rows">10</str>
<str name="fl">*,score</str>
<str name="qf">
content subject^2
</str>
</lst>
<lst name="invariants">
<str name="wt">xslt</str>
<str name="tr">timeline.xsl</str>
</lst>
</requestHandler>
So I'll want a SolrJS Timeline widget that can request to
${base.url}/timeline.xml[?q=....].
However, it is worth noting that a /select?qt=/timeline.xml would work
too - but I think it'd be wiser to not leverage this "backdoor" to
request handler routing.
Maybe I'm being too particular about URLs? But I don't think we want
to rely on /select being there, do we?
There are no fixed ideas behind the current url creation, the current one was
chosen for simplicity reasons. As you mentioned, every handler may be addressed
using /select. But as stated before, these things may be implemented in
siwtchable modules if the needs come up.
matthias
That's the stuff off the top of my head for now. More later as I
hopefully have more time to work with SolrJS for real.
Erik
