cocoon-dev mailing list archives

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

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

> 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
eyes.
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 ;) )

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message