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 <[EMAIL PROTECTED]> - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
