You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/02/13 08:26:32 UTC

Re: Some enlightment regarding scripting language integration please

Hi Christian,

Am Dienstag, den 12.02.2008, 22:12 +0100 schrieb Christian Sprecher:
> Hey guys
> 
> Ok, so I am trying to add a little Groovy-ness to sling. The first
> attempt would be to have Groovy as a scripting possibility. Now, I
> checked out sling, and had a look at the code in the "scripting" branch.
> There are several languages like ruby which implement a ScriptEngine.
> 
> First question: this is JSR 223, right?

Yes.

> 
> Groovy has got a full fledged JSR 223-implementation (see
> http://groovy.codehaus.org/JSR+223+Scripting+with+Groovy). My naive
> approach would be to say that everything is already done to have groovy
> enabled for the sling-platform, no more coding needed (lazy).

Basically, yes, but .... The respective library jar should contain a
services file in the META-INF/services folder pointing to the
ScriptEngineFactory class.

Now the problematic part is, that you need to have a bundle to deploy it
into Sling. This is where it gets a bit more hairy. I suggest you create
a simple Maven project which bundles the groovy-engine.jar file and the
groovy implementation itself in a single bundle and sets the respective
bundle manifest headers. You may use the Apache Felix Bundle plugin [1]
to do this.

> 
> 2nd question (naive): could somebody plz explain how the mapping between
> request and script language works? Is there a place to define the
> GroovyScriptEnginge as the one handling .groovy scripts?

The GroovyScriptEngineFactory implements methods to return the default
script file extensions applying to Groovy scripts. The Sling Scripting
API integration uses this method to create the mapping from the script
file names to the script engines. So there is nothing more to be done on
your part.

> 
> I did read a lot about ResourceResolvers and stuff (and I did not get
> all of it, I must admit), and I am rather unsure about what is currently
> valid documentation and what not.

Yes, this is currently one of the top todos we have .... I am trying to
work on documentation a bit this week and reorganize what we have and
better mark outdated documentation.

Basically, a Resource the is the representation of data Sling is working
on. A request URL is resolved to a Resource, which is then used to
resolve a Servlet or script to call to handle the request.

The Resource itself is just a handle to the actual data: If the Resource
based on a JCR Node, the Servlet or Script handling the request may get
the node by calling the adaptTo(Class) method on the Resource using
"Node.class" as the argument.

Servlets and Sripts are also resources. This enables the uniform
handling of actual data upon which Servlets and Scripts operate and
Servlets and Scripts themselves. In some sense a Resource is comparable
to a java.io.File and the ResourceResolver is the accessor to the files
providing further assistance like resolution of relative path names
(comparable to *nix PATH functionality).

> 
> I would be glad to receive a kickstart, kind of a slingshot pointing in
> the right direction...

If you follow Bertrand's "Discover Sling in 15 minutes" page [1], I hope
you get a very first impression of it all.

Hope this helps

Regards
Felix

[1] http://felix.apache.org/site/maven-bundle-plugin-bnd.html