You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Matthias Epheser <ma...@gmx.at> on 2008/07/01 10:00:55 UTC
First version of solr javascript client to review
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
Re: First version of solr javascript client to review
Posted by Matthias Epheser <ma...@gmx.at>.
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
>>>
>>
>
Re: First version of solr javascript client to review
Posted by Matthias Epheser <ma...@gmx.at>.
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
>>
>
Re: First version of solr javascript client to review
Posted by Matthias Epheser <ma...@gmx.at>.
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
>
Re: First version of solr javascript client to review
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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.
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.
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.
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
Re: First version of solr javascript client to review
Posted by Ryan McKinley <ry...@squid-labs.com>.
Any thoughts / ideas on how to make formatting and laying out custom
results less obtuse?
$sj('<div/>').html(item.id).appendTo(this.target);
seems ok for simple things -- like a list -- but not very designer
friendly.
ryan
On Jul 1, 2008, at 3: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