Hi, Am Samstag, den 29.12.2007, 15:21 -0800 schrieb Padraic Hannon: > This looks promising, I think it will take some time to grok ;-)
Probably, but once you are there ... :-) > The adaptable aspect is especially interesting, do you see this having > a relationship to ocm and mapping mixins? Definitely. I imagine, that the Sling mapping support will register AdapterFactory instances for the mapped classes. This way, we can even separate the core repository access part (JcrResourceResolver) and the OCM part into two separate projects. Mapping mixins would be just as easy: You register a mapping for a mixin node type (e.g. VersionableObject mapping to jcr:versionable) and the OCM support will register an AdapterFactory for Resource to VersionableObject. The only issue at this point is, that a Resource is primarily targeted at reading data. Writing back data would be handled differently and will require support from the OCM directly, I assume. Regards Felix > > -paddy > > On Dec 29, 2007, at 11:51 AM, Felix Meschberger wrote: > > > Hi all, > > > > After the recent thread on scripting "everything" and some off-line > > discussions around this matter, I come to the conclusion, that it is > > about time to introduce the Sling Paradigm: > > > > Everything is a Resource > > > > If Sling would be enhanced to make the ResourceResolver more flexibel > > and powerful by the addition of ResourceProvider instances to define a > > virtual resource tree accessible (and iterable) through the > > ResourceResolver, we can make Sling much more scriptable than it is > > today. > > > > The idea is to make servlets and filters registered as OSGi services > > available through the ResourceResolver just like normal scripts. The > > ServletResolver and Filter handlers could then just ask the > > ResourceResolver for resources and adaptTo(Servlet.class) and > > adaptTo(Filter.class), resp. Calling scripts from other scripts would > > also be available through resolving the script Resource through the > > ResourceResolver and adaptTo(SlingScript.class). > > > > Thus we drop the ScriptResolver, while the SerlvetResolver mainly > > remains for Sling to be able to handle requests. > > > > Of course the adaptor mechanism must be enhanced to make it > > extensible. > > I propose the definition of a Adaptable interface defining the > > adaptTo(Class) method and an AdapterFactory mechanism providing easy > > extensibility. This is built after the Eclipse PlatformObject, > > IAdapterManager and IAdapterFactory but leverages the OSGi service > > registry instead of the Eclipse Plugin mechanism. > > > > I wrote up a wiki page on this concept at [1]. > > > > Comments are welcome. I will try to set up a first prototype in the > > whiteboard in the next few days. > > > > Regards > > Felix > > > > [1] http://cwiki.apache.org/SLING/everything-is-a-resource.html >
