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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
