[Geoserver-devel] REST+Rhino

There's been some buzz around the OpenGeo office recently about all
these slick dynamic languages that run on the JVM, so I've been playing
around with them a bit. I was pretty impressed with how easy it was to
embed Rhino (based on official documentation even!
http://www.mozilla.org/rhino/tutorial.html), so I put together a small
Restlet extension that simply runs JavaScript scripts in the context of
the GeoServer instance (with Rhino making any Java class on the
classpath available to the JS code.) It simply scans a directory in the
datadir for .js files and runs them upon requests. Three global
variables are provided:
* request: the org.restlet.Request instance for the current request
* response: the corresponding org.restlet.Response instance
* catalog: a handle to the GeoServer catalog

You can see how these would be used in the attached script, which
(somewhat clumsily) configures and executes a freemarker template
displaying the names of the available datastores.

Similar extensions could be added for transaction listeners, etc. fairly
easily.

I haven't done anything particularly practical with this module thus
far, but thought it might be interesting to the GS community. If there
are no objections, I'd like to add it as a community module.

Cheers,

--
David Winslow
OpenGeo - http://opengeo.org/

(attachments)

storelist.js (547 Bytes)
storelist.ftl (435 Bytes)

David Winslow ha scritto:

There's been some buzz around the OpenGeo office recently about all
these slick dynamic languages that run on the JVM, so I've been playing
around with them a bit. I was pretty impressed with how easy it was to
embed Rhino (based on official documentation even!
http://www.mozilla.org/rhino/tutorial.html), so I put together a small
Restlet extension that simply runs JavaScript scripts in the context of
the GeoServer instance (with Rhino making any Java class on the
classpath available to the JS code.) It simply scans a directory in the
datadir for .js files and runs them upon requests. Three global
variables are provided:
* request: the org.restlet.Request instance for the current request
* response: the corresponding org.restlet.Response instance
* catalog: a handle to the GeoServer catalog

You can see how these would be used in the attached script, which
(somewhat clumsily) configures and executes a freemarker template
displaying the names of the available datastores.

Similar extensions could be added for transaction listeners, etc. fairly
easily.

I haven't done anything particularly practical with this module thus
far, but thought it might be interesting to the GS community. If there
are no objections, I'd like to add it as a community module.

Hi David,
quite interesting indeed, seems like a great start towards easier
GeoServer customization.

As a matter of fact I've spend the weekend looking into Jython a bit
but I'm still learning the language and have nothing to contribute.

I think in the long run it would be cool to build a facade for these
scripting languages to keep things easy, something like mapscript
(http://mapserver.org/mapscript/) but geared towards the GeoServer
abilities (thus, not a drop in replacement).

Anyways, +1 on the community module, I'm sure it'll attract people's
attention

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

<snip>

Hi David,
quite interesting indeed, seems like a great start towards easier
GeoServer customization.

As a matter of fact I've spend the weekend looking into Jython a bit
but I'm still learning the language and have nothing to contribute.

Interesting, we should talk more... i have been working on something similar but with geotools.

I think in the long run it would be cool to build a facade for these
scripting languages to keep things easy, something like mapscript
(http://mapserver.org/mapscript/) but geared towards the GeoServer
abilities (thus, not a drop in replacement).

Agreed, this would be very cool.

Anyways, +1 on the community module, I'm sure it'll attract people's
attention

+1 as well. It would be cool to think about how to support different types of scripting languages, and what the api will look like for calling scripts, passing in parameters, etc...

Cool stuff :slight_smile:

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.