You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Vidar Ramdal <vi...@idium.no> on 2008/02/06 17:35:47 UTC
Understanding and using the Sling stack
We're building a web content management system, and Sling looks like
it provides a lot of the stuff we need. But we're having a hard time
understanding the Sling technology stack, and where to inject our own
functionality.
Basically, what we need from Sling is a way of mapping URLs to JCR
nodes, and different ways of rendering/styling the content. Our system
will also feature other functionality than just content management,
like webshop, feedback forms etc., so we cannot depend on the JCR to
store all of our application's data.
Examples of how to build an application upon the Sling framework would
be of great help to us.
This page at http://incubator.apache.org/sling/site/sling-api.html
leaves a lot to our imagination (granted, it is labeled as being "work
in progress" - we're anxiously waiting for more details here). This
sentence, in particular, is confusing to us:
"An implementation of the presentation framework defined by the Sling
API is called a Sling Framework. The Apache Sling project actually
contains two implementations of this API: microsling and Sling.
microsling (note the lowercase m) implements the same request
processing mechanisms as Sling but is very hardcoded. [...] Sling on
the other hand is based on an OSGi framework and very flexible,
allowing the extension of the system in various ways."
The term "Sling" seems to mean at least 3 different things. Sling and
microsling in the Apache Sling project are implementations of the
Sling API, thus making them Sling frameworks? Huh?
So, basically, we're not sure what would be the best way to make use
of the great functionality that comes with Sling. Should we:
a) Build our application directly on top of Sling, extending Sling's
interfaces and classes (would this make our application a "Sling
framework"?) ;
b) Run Sling as a standalone application, and let our application
access Sling via RMI/JSON calls or whatever remote interfaces are
available;
c) Build our functionality as an OSGi bundle, and run it side-by-side
with the Sling bundles (although the concept of OSGi seems to be a bit
overkill for our application);
d) Build our functionality as scripts that are stored in the
repository (not really an option)
If anyone could attempt to clarify our options a bit, it would be
greatly appreciated.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Understanding and using the Sling stack
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Feb 7, 2008 8:35 AM, Vidar Ramdal <vi...@idium.no> wrote:
> ...What I have envisioned, is creating servlets that extends e.g.
> SlingAllMethodsServlet. Our servlet will examine the request, pass the
> request on to Sling in some cases, or pass it on to our own code in
> other cases. Is this strategy at all possible and advisable?...
Right now it's the other way around: based on configuration properties
of your Servlet, like in my previous example:
* @scr.property
* name="sling.servlet.resourceTypes"
* value="scr/test"
Sling selects a suitable Servlet from the list of all registered ones.
The possible configuration properties are listed at [1] - I think that
page is up to date, but I'm not sure if all combinations currently
work and/or are included in our automated tests.
We did talk about inverting the mechanism, i.e. allowing Servlets to
decide by themselves if they want to handle the request or not. This
is not implemented nor designed at the moment, but if really needed
that shouldn't be too hard to implement - but it's probably in the
YAGNI category at the moment.
-Bertrand
[1] http://incubator.apache.org/sling/site/servlet-resolution.html
Re: Understanding and using the Sling stack
Posted by Vidar Ramdal <vi...@idium.no>.
Thank you, your answer is very clarifying.
On 2/6/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> > ...Examples of how to build an application upon the Sling framework would
> > be of great help to us....
>
> We don't have any serious examples at the moment, this is definitely
> next on our list [...]
Great, we will keep watching the doc pages.
> We'll have examples for the Launchpad...hopefully soon.
Yep, those examples would definitely be valuable to us.
> > ...c) Build our functionality as an OSGi bundle, and run it side-by-side
> > with the Sling bundles (although the concept of OSGi seems to be a bit
> > overkill for our application);...
>
> > ...d) Build our functionality as scripts that are stored in the
> > repository (not really an option)...
>
> A combination of c) and d) is how we envision Sling being used in most
> cases: start by creating scripts to experiment and prototype, and
> where needed moved to Servlets and other Java-based components,
> provide as OSGi bundles.
Our application will handle hundreds of websites, so performance is a
big issue here. Thus, we're reluctant to store too much of our core
functionality in JCR - having precompiled Java classes will probably
be much more efficient in many areas.
What I have envisioned, is creating servlets that extends e.g.
SlingAllMethodsServlet. Our servlet will examine the request, pass the
request on to Sling in some cases, or pass it on to our own code in
other cases. Is this strategy at all possible and advisable?
> [2] http://felix.apache.org/site/maven-scr-plugin.html
I didn't realize what the SCR plugin could do for us. Will definitely
have a look at it.
> Hope this helps - Sling is still a young project, so we don't have as
> much examples and up to date documentation as we'd like, but if you're
> willing to invest some time in playing with it, I'm sure the people on
> this list would be happy to help.
We're very excited about Sling, and will continue to keep a close
watch on what's happening. Thanks for some great advise!
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Understanding and using the Sling stack
Posted by er...@acquitygroup.com.
MLWwwwwwwwwwwwwwwqqqqqqqqqQqqqqqqqqkjtttTtttttTPpppppppppqq
Sent via BlackBerry by AT&T
-----Original Message-----
From: "Bertrand Delacretaz" <bd...@apache.org>
Date: Wed, 6 Feb 2008 23:12:10
To:sling-dev@incubator.apache.org
Subject: Re: Understanding and using the Sling stack
Hi Vidar,
On Feb 6, 2008 5:35 PM, Vidar Ramdal <vi...@idium.no> wrote:
> ...what we need from Sling is a way of mapping URLs to JCR
> nodes, and different ways of rendering/styling the content....
Sling will definitely help you here, taking care of the URL to node
mapping (called "resolving the resource" in slingspeak), and selection
and execution of scripts or servlets for rendering and styling.
>... Our system
> will also feature other functionality than just content management,
> like webshop, feedback forms etc., so we cannot depend on the JCR to
> store all of our application's data....
Ok - many of us JCR people believe that you can store most everything
in JCR, given the right content models. Yet, if you really need
something else, Sling's use of OSGi allows you to do whatever.
> ...Examples of how to build an application upon the Sling framework would
> be of great help to us....
We don't have any serious examples at the moment, this is definitely
next on our list once Sling and the Launchpad stabilize (which is
happening quickly as we speak), but nothing serious here and now
unfortunately.
> ...This page at http://incubator.apache.org/sling/site/sling-api.html
> leaves a lot to our imagination...
Agreed, a solid example would help a lot in understanding the
concepts, and some parts of that page ("Content and Component" in
particular) are obsolete.
> ...The term "Sling" seems to mean at least 3 different things. Sling and
> microsling in the Apache Sling project are implementations of the
> Sling API, thus making them Sling frameworks? Huh?...
Not anymore - microsling has been merged into Sling. What we have now
is Sling (the applications framework, implemented as a set of OSGi
modules, "bundles"), and the Sling Launchpad [1], which is a
ready-to-run assembly of such modules. We'll have examples for the
Launchpad...hopefully soon.
[1] http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html
> ...Should we:
> a) Build our application directly on top of Sling, extending Sling's
> interfaces and classes (would this make our application a "Sling
> framework"?) ;...
Part of your app will probably be implemented like this, but the more
you can use Sling components out of the box the easier it will be,
IMHO. And we're open to contributions for things that wouldn't match
your requirements, assuming the required changes are of general
interest.
> ...b) Run Sling as a standalone application, and let our application
> access Sling via RMI/JSON calls or whatever remote interfaces are
> available;...
Not recommended, and probably not needed.
> ...c) Build our functionality as an OSGi bundle, and run it side-by-side
> with the Sling bundles (although the concept of OSGi seems to be a bit
> overkill for our application);...
> ...d) Build our functionality as scripts that are stored in the
> repository (not really an option)...
A combination of c) and d) is how we envision Sling being used in most
cases: start by creating scripts to experiment and prototype, and
where needed moved to Servlets and other Java-based components,
provide as OSGi bundles.
Creating OSGi bundles is really easy with the Felix SCR plugin [2]: a
few annotations in classes that are OSGi services (like the Servlets
that Sling uses), setup the maven-scr-plugin in the module's Maven pom
and you're in business.
[2] http://felix.apache.org/site/maven-scr-plugin.html
For example, to make a plain Servlet usable by Sling, you'll only have
to add something like this in the class comments:
/**
* Minimal Sling Servlet example
*
* Our servlet must be an SCR component:
* @scr.component
* immediate="true"
* metatype="false"
*
* Our servlet must also be an SCR service:
* @scr.service
* interface="javax.servlet.Servlet"
*
* And we tell Sling which Resource types we handle:
* @scr.property
* name="sling.servlet.resourceTypes"
* value="scr/test"
*/
This, and the Maven pom settings described in [2], are sufficient to
create an OSGi bundle that Sling can use to process and render content
for JCR nodes which have sling:resourceType=scr/test .
And Sling provides all the infrastructure to load, configure and
manage the modules, so you won't need to learn much about OSGi to be
able to plugin your Servlets and component into Sling.
Hope this helps - Sling is still a young project, so we don't have as
much examples and up to date documentation as we'd like, but if you're
willing to invest some time in playing with it, I'm sure the people on
this list would be happy to help.
-Bertrand
Re: Understanding and using the Sling stack
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Vidar,
On Feb 6, 2008 5:35 PM, Vidar Ramdal <vi...@idium.no> wrote:
> ...what we need from Sling is a way of mapping URLs to JCR
> nodes, and different ways of rendering/styling the content....
Sling will definitely help you here, taking care of the URL to node
mapping (called "resolving the resource" in slingspeak), and selection
and execution of scripts or servlets for rendering and styling.
>... Our system
> will also feature other functionality than just content management,
> like webshop, feedback forms etc., so we cannot depend on the JCR to
> store all of our application's data....
Ok - many of us JCR people believe that you can store most everything
in JCR, given the right content models. Yet, if you really need
something else, Sling's use of OSGi allows you to do whatever.
> ...Examples of how to build an application upon the Sling framework would
> be of great help to us....
We don't have any serious examples at the moment, this is definitely
next on our list once Sling and the Launchpad stabilize (which is
happening quickly as we speak), but nothing serious here and now
unfortunately.
> ...This page at http://incubator.apache.org/sling/site/sling-api.html
> leaves a lot to our imagination...
Agreed, a solid example would help a lot in understanding the
concepts, and some parts of that page ("Content and Component" in
particular) are obsolete.
> ...The term "Sling" seems to mean at least 3 different things. Sling and
> microsling in the Apache Sling project are implementations of the
> Sling API, thus making them Sling frameworks? Huh?...
Not anymore - microsling has been merged into Sling. What we have now
is Sling (the applications framework, implemented as a set of OSGi
modules, "bundles"), and the Sling Launchpad [1], which is a
ready-to-run assembly of such modules. We'll have examples for the
Launchpad...hopefully soon.
[1] http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html
> ...Should we:
> a) Build our application directly on top of Sling, extending Sling's
> interfaces and classes (would this make our application a "Sling
> framework"?) ;...
Part of your app will probably be implemented like this, but the more
you can use Sling components out of the box the easier it will be,
IMHO. And we're open to contributions for things that wouldn't match
your requirements, assuming the required changes are of general
interest.
> ...b) Run Sling as a standalone application, and let our application
> access Sling via RMI/JSON calls or whatever remote interfaces are
> available;...
Not recommended, and probably not needed.
> ...c) Build our functionality as an OSGi bundle, and run it side-by-side
> with the Sling bundles (although the concept of OSGi seems to be a bit
> overkill for our application);...
> ...d) Build our functionality as scripts that are stored in the
> repository (not really an option)...
A combination of c) and d) is how we envision Sling being used in most
cases: start by creating scripts to experiment and prototype, and
where needed moved to Servlets and other Java-based components,
provide as OSGi bundles.
Creating OSGi bundles is really easy with the Felix SCR plugin [2]: a
few annotations in classes that are OSGi services (like the Servlets
that Sling uses), setup the maven-scr-plugin in the module's Maven pom
and you're in business.
[2] http://felix.apache.org/site/maven-scr-plugin.html
For example, to make a plain Servlet usable by Sling, you'll only have
to add something like this in the class comments:
/**
* Minimal Sling Servlet example
*
* Our servlet must be an SCR component:
* @scr.component
* immediate="true"
* metatype="false"
*
* Our servlet must also be an SCR service:
* @scr.service
* interface="javax.servlet.Servlet"
*
* And we tell Sling which Resource types we handle:
* @scr.property
* name="sling.servlet.resourceTypes"
* value="scr/test"
*/
This, and the Maven pom settings described in [2], are sufficient to
create an OSGi bundle that Sling can use to process and render content
for JCR nodes which have sling:resourceType=scr/test .
And Sling provides all the infrastructure to load, configure and
manage the modules, so you won't need to learn much about OSGi to be
able to plugin your Servlets and component into Sling.
Hope this helps - Sling is still a young project, so we don't have as
much examples and up to date documentation as we'd like, but if you're
willing to invest some time in playing with it, I'm sure the people on
this list would be happy to help.
-Bertrand