cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Defining Source Interfaces
Date Wed, 08 Jan 2003 14:22:22 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Carsten Ziegeler wrote:
>>Cool. But I'm still not that happy with these methods being on Source
>>itself. What about TraversableSource or HierarchicalSource (I have this
>>last one ready on my PC with collections) ?
>I really don't like all these instanceof tests and I think that a source
>can have children is very common. So if you deal with sources you always
>end up with a test if this source contains children or not.
>I think this test is much more cleaner/nicer/whatever if I can directly
>query the source. An instanceof test for this reason is not appropriate.

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 

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.

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.

Finally, what about WriteableSource, VersionableSource, LockableSource, 
InspectableSource, etc ? Should we merge their methods to Source ? If 
not, then why a particular case for TraversableSource ?

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.

Your turn, now ;-)


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

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

View raw message