cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: [RT] Source extensions
Date Thu, 09 Oct 2003 17:47:39 GMT
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 <Unico@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.


Mime
View raw message