Hi Unico, first let me say thank you for all you efforts in this area. I'm very excited about that (I start wondering ...). I'm sorry I cannot help out more currently.
Unico Hommes <[EMAIL PROTECTED]> wrote: > Hi, > > This is to let you know I've just submitted a patch [1] to cocoon > bugzilla for some enhancements to the SourceInspector code. It solves > the problem of more efficiently finding specific properties than is > the case now. You may also be interested in a related patch [2] I > submitted earlier for basing SourceDescriptionGenerator on the > emerging TraversableGenerator that is now still in the scratchpad > area. I hope you like the enhancements and look forward to any > comments or questions you may have. > > One of the things I've noticed that I would like to discuss is that > the Source extensions such as LockableSource, InspectableSource, etc. > are currently all located inside the Slide block, whereas they should > probably be located in a more general block (a repository block?) or > else move them to excalibur sourceresolve. I thought about that as well. The problem is that some of them do not seem general enough to move to excalibur. I'm +1 for a separate block although I'm not sure about the name. > > I'd like to review some the issues I came across while exploring this > package. > > > ---- SourceProperties ---- > > A SourceProperty is a piece of meta data in the form of an XML > element that can be associated with a Source. Currently the API > separates 'live' properties from 'computed' properties by handling > them in different ways. > > Computed properties are handled by components that implement the > SourceInspector interface [3]. Current implementations include > [Image]SourceInspectors that support 'width' and 'height' properties > and an XPathSourceInspector that queries a Source its XML content. > Modifiable properties on the other hand seem to be covered by the > InspectableSource interface [4] that has methods for setting and > removing SourceProperties. > > As these interfaces seem to partly overlap I think it would be useful > to try and merge them or choose between one or the other. What I like > about SourceInspector interface is the ability to plug in different > implementations of property handlers. We could extend the function of > SourceInspectors to support writing SourceProperties and then > deprecate InspectableSource. Off course the SourceInspector would > have evolved into something else that would probably be better > described by a different name (SourceDescriptor?). This would allow > the definition of different datasources for storing SourceProperties > too. (I actually have a use case for that). I like that. A SourceInspector implementation for inspect-enabling any ModifiableSource. Another step forward (besides RequestFactories) for making Cocoon a great WebDAV Server. However I still feel the SourceInspector covers a different need than a natively inspectable source. It sort of enhances source implementations with additional properties. A natively inspectable source does not need a SourceInspector for ordinary explicitely managed properties (with read/write access only through the InspectableSource interface). However I'm +1 making the SourceInspector support modifiable properties. > > As individual Source protocols may have their own way of storing > properties (f.i. a WebDAV Source), special SourceDescriptor > implementations will still be able to cover those situations > elegantly. As it stands today the SourceInspector does not (and should not) care about the source implementation so it works with any source. But I may be just missing the point. I could however imagine a special Source implementation that will be configured for which SourceInspector implementation to use to inspect-enable modifiable sources (like FileSource). > > > ---- Other Source meta data ---- > > The other Source extensions that exist in the Slide block all deal > with a seperate area of meta management of Sources. Except for > VersionableSource interface I have not reviewed them very well yet > but am wondering inhowfar these could be covered by just > SourceProperties (I am just guessing here). At the very least I am > concerned with the fact that implementing all these different > interfaces leads to rather large class definitions. > > Comments? I share the concern that the Source classes get bigger and bigger. However I fail to see how outsourcing the inspectable part solves the problem in general. I think this should be decided from case to case (LockableSource comes to mind). Not being familiar with JSR147 or JSR170 I wonder how these approaches deal with it. BTW wasn't a JSR170 draft available somewhere? For the WebDAVSource (being based on the Slide webdav client lib) it would be more convienient (implementation-wise) to leave the inspectable code there. Guido > > Regards, Unico > > > [1]. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23694 > > [2]. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23699 > > [3] > http://birgit.s.castasoftware.com:3080/api/java/org/apache/cocoon/compon ents/source/InspectableSource.html > * > > [4] > http://birgit.s.castasoftware.com:3080/api/java/org/apache/cocoon/compon ents/source/InspectableSource.html > * > > > * The cocoon website does not seem to list the complete javadocs.
