cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Defining Source Interfaces
Date Wed, 08 Jan 2003 14:30:58 GMT

Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
> 
>>Carsten Ziegeler wrote:
>>
>>>Sylvain Wallez wrote:
>>>
>>
>>[...]
>>
>>>>You're totally on track. If you need this action right now, I would
>>>>suggest to mimic what's in the DirectoryGenerator, that makes the
>>>>assumption that the Source is a file. You can then use all the
>>>>facilities given by File.
>>>>
>>>
>>>And we only argue, if this support should belong to the Source interface
>>>or too an optional extension interface where I always have to do
>>>an instanceof to see if the source has childs or not.
>>>
>>>:)
>>
>>It's nice when discussions are about where to put something new, it's
>>always goodness :-)
>>
> 
> Yupp!
> 
> 
>>MHO: It all depends on what a Source is.
>>
>>1 - If a source is a plug to a URI-based source handler, it should have
>>children.
>>2  -If it's a plug to a resource, it should not.
>>
>>Usually a source is (2), but since we bind the Source to a URI, (1)
>>makes more sense. BTW, if (2) is true, specific Sources should probably
>>not be the place anyway where to traverse a URI space, or else we are in
>>case (1).
> 
> So you tend to {1}, right?

Your're German, right? Always trying to make a clean cut? ;-)

Define what a Source is and you will have the answer... if the source 
interface has anything to do with a URI, it's {1}, else {1} is not it's 
concern, but a concern of who gave you the Source, hence it would be {2}.

>>Also, a source should IMNSHO do stream2xml conversion. It should pipe
>>directly XML *only* if the source is itself already in xml form, like
>>for example a precompiled SAX stream or a direct plugged in SAX stream
>>(for example in the future bean env).
>>
>>This makes the whole system more flexible, because we can easily change
>>Generators to make the stream2xml conversion phase pluggale. If we make
>>sources do all the conversion, we are back to Generators, and I don't
>>see the real benfit other than syntatic sugar...
>>
> 
> Sorry, you totally lost me..(what is IMNSHO?)

InMyNotSoHumbleOpinion

> A source by itself has nothing to do with XML or sax events. A source
> can still implement the XMLizable interface for sax streaming. We have
> the Cocoon SourceResolver which has a toSAX() method for a Source
> object.
> This method checks for the XMLizable interface. If the source implements
> it, it's used. If not, the XMLizer component from excalibur is used
> which does a mime-type to sax conversion and is therefore pluggable.
> 
> Is it that what you meant?

Errr, the context is that, yes. My point is that a *Generator* should do 
the stream to sax conversion, not the source. This maintains cleaner SOC.

If a Source *is* XML, then implementing XMLizable makes sense (XMLDB).
If it's not, it doesn't, because a Generator should do it.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message