Hi,
I just made a commit to http://solrstuff.org/svn/solrjs, containing the
following changes:
A) Build system
The single javascript file became a bit long, so I decided to create a new
directory structure and a small build file:
src/ -> single javascript files for every "class"
lib/ -> external libs
test/ -> html test files for server and client side widgets
testsolr/ -> a solr test instance that conatins the velocity patch for a
quickstart (see description below)
build.xml -> "ant dist" creates a single javascript file in the dist folder that
concatenates the single js files in correct order. We later may add some ant
task for javascript compression, so we can deliver a compressed and uncompressed
js file. (see
http://blog.tremend.ro/2006/10/25/ant-task-for-javascript-compression/)
B) base classes for client and server side widgets
Two abstract classes are added in src/core:
- AbstractClientSideWidget: uses the json response writer
- AbstractServerSideWidget: uses the velocity response writer. children have to
implement the getTemplateName method
See the 2 testfiles in test/ for examples.
C) Testsolr including velocity patch and context for static resources
I know it's not common to check in a solr distribution, and it's just for an
easier quickstart with the velocity tests.
While implementing the server side widgets, I came along the cross site ajax
problem: jquery supports cross site requests only for json with the getJSON
method (creating a dynamic script tag), but the standard "load" method that is
used to get html from the server uses standard XMLHTTP requests.
So I created a context for the testsolr that points to the trunk checkout of
solrjs, jetty now serves solr AND solrjs. In a productive environment, there are
several options to get around the problem (eg. Apache proxy for solr and html).
As I was't able to use relative paths yet, you may change the path to the
checkout in testsolt/contexts/solrjs.xml.
I also included the newest patch for
https://issues.apache.org/jira/browse/SOLR-620 and added a result.vm file in
testsolr/solr/conf/velocity/
For a quick test, just change the path in the context file, start the testsolr
server and point the browser to test/test*.html.
regards
matthias
Matthias Epheser schrieb:
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