Erik Hatcher schrieb:
Mattias,
Nice start!
One comment....
In test.html:
new $sj.solrjs.Manager({solrUrl:"http://localhost:8983/solr/select"});
It would be better to omit the "/select" from the base URL. Consider
Solr rooted at a particular URL without the request handler mapping
attached to it, and allow the "/select" or "qt=whatever" to be added at
a different stage. This way SolrJS can attach to any number of request
handlers depending on context.
yep sounds good. In fact, this url can be used very customized. It just has to
be the url that delivers the json/html/whatever, Maybe some users use a proxy
(eg apache) to mount a solr select under "www.mydomain.com/solrrequest" or similar.
So we could split it into three parameters for the manager: "baseUrl" (eg.
http://localhost:8983/solr/), "selectPath" (eg. select) and "querytype" (eg.
"standard"). baseUrl should be mandatory, the others should provide the default
values if not specified.
Ryan commented on using something besides JavaScript to generate HTML
pieces. One alternative that I propose is to use a
VelocityResponseWriter (see SOLR-620 for a first draft) to generate the
HTML framework which SolrJS can then deal with. I'm personally fonder
of the bulk of HTML generated server-side, even snippets that are AJAXed
in, leaving SolrJS to mainly deal with widgets and getting JSON data to
them when HTML generation doesn't make sense. SOLR-620 is still raw,
and needs some work to make it really easy to leverage, but I wanted to
toss it out there for folks to improve upon as needed.
The first draft looks good. I'll test it in a template with the standard solr
response object, maybe it will be handier to use the SolrJ one or another
wrapper object that provides easier access
to the response values.
Concerning HTML creation:
I like your suggestion, and as we are very flexible on the client, I propose
building two "base classes" upon AbstractWidget":
- AbstractServerSideWidget: these widgets specify the template file parameter
and "paste" the response simply into the target div. Every widget will get an id
inside the manager (currently it's simply an incremented integer) and pass this
id as requets parameter to the solr server, so you can create action links in
the velocity template like:
<a href="javascript:solrjsManager.selectItems(#widgetid#,queryItems)"> link </a>
- AbstractClientSideWidget: These work like the existing example, retrieving
json objects and create html using jquery.
I think it strongly depends on the widgets nature which one suits better.
Also, consider wiring in a SIMILE Timeline (or perhaps even SIMILE
Exhibit) widget - it'd make for a snazzy example :) Of course, Google
Maps would make a great example as well.
Yep, I'll add them to the wiki page. Once the velocity integration and
implementation of the two mentioned base classes is finished, we can start
building our widgets. I'll try to get a velocity example widget running in the
next few days and will post a small message in this list when trunk is updated
regards,
matthias
Erik
On Jul 1, 2008, at 4:00 AM, Matthias Epheser wrote:
Hi community,
as described here
http://www.nabble.com/Announcement-of-Solr-Javascript-Client-to17462581.html I
started to work on a javascript widget library for solr.
I've now finished the basic framework work:
- creating a jquery environment
- creating helpers for jquery inheritance
- testing the json communication between client and solr
- creating a base class "AbstractWidget"
After that, I implemented a SimpleFacet widget and 2 ResultViews to
show how these things will work in the new jquery environment.
A new wiki page documents this progress:
http://wiki.apache.org/solr/SolrJS
Check out the trunk at:
http://solrstuff.org/svn/solrjs/trunk/
Feedback about the implementation, the quality of code (documentation,
integration into html, customizing the widgets) as well as ideas for
future widgets etc. is very welcome.
regards
matthias
