Hi all, Start a discussion on working on the current Component API in [1] Carsten launched a discsussion on simplifying the API and leaning more towards the original Servlet API. I took this up in issue 28 [2] and now committed a large chunk of updates to the sling-api project. This update is inspired by the recent discussions on the list and the evolution of microsling.
To summarize, these are the most dramatic changes: * Content and Component removed The Content interface is replaced by the more generic Resource interface providing access to the JCR Item and the mapped object. The Component interface is removed. Instead the Servlet interface is used by Sling. The former API of the Component interface to get the Content class name and create Content objects was not really used and thus has been removed without replacement. In the future servlets will be registered as OSGi services which provide their identification as part of the service registration properties. * ResourceResolver The ResourceResolver is added and provides the functionality to access Resources and list children, which was formerly provided by the SlingRequest interface. A new ResourceManager interface extending the ResourceResolver is added, which may be implemented to provide seemless content mapping. The ResourceManager extends ResourceResolver and servlets may cast to get the functionality. * Renamed SlingRequest/Response The SlingRequest and SlingResponse interfaces are renamed to SlingHttpServletRequest and SlingHttpServletResponse respectively to clearly indicated that they are an extension to the respective Servlet API interfaces. The microsling SlingRequestContext is not migrated into the Sling API as it showed that it is easier to an extended Servlet Request/Response API than to always access a context from the request attributes. Through carefull implementation of request and response wrappers integration issues are minimized, too. * RequestPathInfo The RequestPathInfo interface is new and replaces the selector, extension, and suffix accessor methods formerly in the SlingRequest interface. * Manifest Servlet and Script support The core interfaces to implement servlet and scripting support are made part of the Sling API. Though, generally servlet implementors will not be confronted by these interfaces, the are made part of the API to be able to more easily explain how Sling is intended to work. * Removed "duplicate" interfaces ComponentFilter and ComponentFilterChain are removed. Instead the Servlet API Filter interface will be used. Likewise the ComponentContext, ComponentSession (with ComponentSessionUtil) are removed because they are not used anymore and do not provide any more functionality. * Additional helpers Additional helpers have been added: ProcessTracker, which may be used to track progress of request processing for debugging etc. purposes, and ServiceLocator, which may be used by servlets (most prominently scripts not loaded through OSGi) to access services. I would like to open the discussion now on this .... Any comments are welcome. Thanks in advance. Regards Felix PS: Yes, the vote I wanted to hold some weeks ago has of course never taken place due to the big impact the microsling initiative had on all this :-) [1] http://www.mail-archive.com/[email protected]/msg00177.html [2] http://issues.apache.org/jira/browse/SLING-28
