Felix Meschberger wrote: > > I looked at the Excalibur resolver. This sure lookes very interesting. Yet, I > have some missing links: > > (1) The Excalibur Source provides access to file-like data, where the > intent of our Content was to access mainly "structured" data in terms of > properties and child objects with properties. > > (2) The Excalibur Source is intelligent in the sense, that it may > implement additional interfaces like Modifiable, Traversable, ... > > Trying to map this on our ContentResolver and Content, I would probably > get something like this: > > * A request URL (e.g. http://xy.com/some/index.html) is resolved to some > Resource URL (e.g. jcr:/some/index). > * The Resource URL is resolved to a Resource instance providing > operative API comparable to the API provided by the Excalibur > MovableSource, ModifiableSource, ... > * The Resource provides a method getContent() returning the "mapped" > Content - in case of JCR this might be Jackrabbit OCM mapped, in case of > a filesystem File this might be an XML DOM or a loaded Properties object > (depending on the MIME-type). > > What would then be the consequences for the Sling API ? Of course there > is no single ContentManager but comparable to Excalibur something like > ResourceResolver (mapping scheme to ResourceFactory), ResourceFactory > and Resource. > Hmm, I haven't thought about this yet, but I would like to give some more information about the excalibur stuff first :)
The excalibur sourceresolver is one of the greatest components I ever saw as it provides a uniform way to access different data sources. Everything is identified by a url. This component is key of Cocoon and and is one of the reasons why Cocoon is so flexible. There are some additions to the sourceresolver stuff for Cocoon, e.g. if a source is able to stream its content as XML it implements another interface (XMLizable from excalibur xmlutils) and the xml can be directly streamed using sax events. Now, all this sounds very cool and indeed it is - but users always had the problem that they had to use the source resolver instead of plain java.net.url classes. So before getting content you needed to get a source resolver first. If you know how to do this, its really easy, but if not it is painfull. Therefore we always had the dream in Cocoon to use plain java.net classes to access any resource. In the last weeks I developed the excalibur jnet package which hopefully makes this dream come true in the near future. It is a package which is able to install own url handlers in a webapp environment and which is able to make source implementations available through java.net.URL class. The idea is to use well known api and classes to access custom stuff. Even for the XML streaming stuff, I created a prototype which (ab)uses the getContent(Class[]) method. So, to keep this long story short, we should try to use existing api if it makes sense instead of creating new interfaces for things that already exist. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
