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'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).
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.
---- 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?
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/components/source/InspectableSource.html
*
[4]
http://birgit.s.castasoftware.com:3080/api/java/org/apache/cocoon/components/source/InspectableSource.html
*
* The cocoon website does not seem to list the complete javadocs.
