Redesign of the Sling API
There have been a number of threads on the Sling Dev Mailing List on simplifying the current Component API and turn it into a new Sling API. This page starts at the current state of the discussion as of Oct. 10, 2007, and tries to summarize what has been discussed and to resolve this into a modified proposal.
References
- SLING-28, Simplify the Sling (aka Component) API
- Simplifying our component api - The original thread launched by Carsten
- Move ContentManager to Sling API - My own proposal to make the ContentManager part of the Sling API
- Breaking Sling into smaller pieces? - Bertrand's proposal to further modularize parts of Sling such as the current sling-core bundle
Current State
Currently, request processing is controlled by the sling-core bundle using two sets of filters: one set called at the time the client request enters Sling - so called request level filters - and the other set called for each Content object processed during request processing - so called content level filters.
Amongst the request level filters is the ContentResolverFilter which takes the request URL and finds a Content object for the URL. This filter implements the ContentResolver interface and is also registered as this service. So other parts of the system may use the same mechanism to resolve paths to Content objects. The ContentResolver also implements the default content loading described here.
Amongst the content level filters is the ComponentResolverFilter which asks the Content object for its component ID and resolves this ID using the registered {{Component}}s. This filter also implements the default component resolution described here.
To manage content Sling provides two interfaces: the ContentManager interface and the JcrContentManager interface.