Hi, Am Freitag, den 26.10.2007, 13:39 +0200 schrieb Carsten Ziegeler: > With the new service locator using a type as an argument, I think we can > drop the NAME constant from the SlingScriptResolver interface.
You are of course right :-) Regards Felix > > Carsten > > Felix Meschberger wrote: > > 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 > > > > > >
