cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject [RT] Source extensions
Date Thu, 09 Oct 2003 15:16:07 GMT

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.

Mime
View raw message