cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: Defining Source Interfaces
Date Wed, 08 Jan 2003 14:26:43 GMT

Sylvain Wallez wrote:
> Okay. Let me throw in more arguments ;-)

> How many protocols do we have for which parent and children make sense ?
> Actually 2 : 'file' and 'slide' (and 'cvs' soon). For other protocols
> such as 'cocoon', 'resource', 'blob', 'xmldb', 'http', etc, this has no
> meaning.
> How many components do we have that use a source's parent and children ?
> Actually one : DirectoryGenerator, or its TraversableSource counterpart.
> So should we add a lot of methods to Source for these few protocols and
> components ? I would say no.
Ok, seems reasonable.

> Furthermore, I consider that DirectoryGenerator should fail hard if we
> try to generate from a source that is not traversable (as it does today
> if it's not given a file). So we should be able to know not only if a
> Source has children or not, but if it actually supports this feature.
Yes. true. A isTraversable() would work.

> Finally, what about WriteableSource, VersionableSource, LockableSource,
> InspectableSource, etc ? Should we merge their methods to Source ? If
> not, then why a particular case for TraversableSource ?
Hmm, nice point. Yes, if it's true that a TraversableSource is only
used in 5% of the cases then it should be a separate interface.
The others you mention above are of course separate interface, so you're
right that it's only natural separate TraversableSource as well.

> And as far as code cleanliness is concerned, an "instanceof" test seems
> more OOP to me than a isTraversable() method that tells us if is we have
> the right to use getParent() and getChildren(). With a separate
> interface, these methods do not exist if they do not make sense.
This is a point were a not really agree with. If I always have to do
instanceof tests and class casts, something is wrong with OOP then in my
Anyway, I think your arguments are better than mine (sniff).

So, we have a TraversableSource or HierarchicalSource or ...?

What do you think about the ModifiableSource in Excalibur? (That should be
the replacement for WriteableSource - please let *me* win this time ;) )


To unsubscribe, e-mail:
For additional commands, email:

View raw message