avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Component Design Question
Date Wed, 17 Apr 2002 21:24:00 GMT
On Thu, 18 Apr 2002 00:34, Carsten Ziegeler wrote:
> Peter Donald wrote:
> > Hmmm. Not sure I got across what I meant to. Basically it came
> > down to this.
> > If you don't implment XMLizable (and thus decouple from xml.*
> > package) then
> > you can reuse the whole package in other contexts.
>
> Yes, this was the intension of the initial decoupling XMLizable
> from the Source interface.
> Unfortunately, the implementations of the Source package are
> tied to the xml package as they already implement XMLizable.

True but I would recomend un-coupling them personally ;)

> It is possible. If the Source interface would extend the XMLizable
> interface and you resolve an html file the implementation of the
> XMLizable interface could either return an exception or use
> jtidy to convert it etc. If you don't need XML and your context,
> you don't have to use it.

Again I would consider the conversion to XML (and optional normalization and 
cleanup with jtidy or whatever) to be the concern of a different component. I 
would probably have a different converter project to do this

> b) Source does not extend XMLizable but the Implementations do
> Disadvantages: No decoupling and instanceof is required.
...
> d) Source does not extend XMLizable and does not care about XML, too
> As you pointed out in your other email in this thread, it is very
> easy to make out of the input stream provided by the Source object
> a sax stream.
> Advantage: Decoupled, no instanceof required

+1 to either of above

> Now, looking at this list d) seems to be the way to go, but what
> about more "abstract" Sources which provide an InputStream which
> does not deliver XML and only the XMLizable interface adds this
> functionality? I think, we have some of them in Cocoon already... 

2 options here. 

[1] We add an extra component to do conversion of stream to xml (I assume this 
is for converting things like excel into XML??? or .psd files to svga??). So 
what I would do in this case is then add a "getMimeType()" to the Source 
interface that returns a string about what type the underlying file. Then 
have another set of components that convert objects of different mimetypes to 
xml streams.

This is the same architecture as used in the Java URL system ie they have 
stream handlers (which are like Source objects) and ContentHandlers (which 
are like converters between stream and object type).

[2] Make the sources implement XMLizable ;) Personally I have no problem with 
the "object instanceof XMLizable" statement though and don't really consider 
it a problem. 

I really think [1] is the right way to go but it is also more work so I would 
suggest that you go with [2] for now if there is a deadline looming else go 
with [1]

> The question is, is the coupling of the packages xml and source
> really so bad?

It would stop me using it :)

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message