With the new service locator using a type as an argument, I think we can drop the NAME constant from the SlingScriptResolver interface.
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 > > -- Carsten Ziegeler [EMAIL PROTECTED]
