a small improvement:
I just managed to get relative paths for the test jetty working, so to you just
have to:
cd testsolr
java -jar start.jar
open http://localhost:8983/solrjs/test/testServerside.html
regards,
matthias
Matthias Epheser schrieb:
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
