You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Unico Hommes <Un...@hippo.nl> on 2003/10/09 17:16:07 UTC
[RT] Source extensions
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.
Re: [RT] Source extensions
Posted by Guido Casper <gc...@s-und-n.de>.
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 <Un...@hippo.nl> 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.