inteface Serializer
{
DocumentHandler asDocumentHandler();
. . .
}
?
arkin
Stefano Mazzocchi wrote:
>
> Scott Boag/CAM/Lotus wrote:
> >
> > Stefano Mazzocchi said:
> > > propose to start discussing some XML Output API to propose an addiction
> > > to the proposed Sun's XML Java API that currently lack output features:
> > >
> > > interface Serializer() extends DocumentHandler {
> > >
> > > void setOutputFormat(OutputFormat);setOutputByteStream(OutputStream
> > > output);
> > > void setOutputCharStream(Writer output);
> > >
> > > void serialize(Element elem) throws IOException;
> > > void serialize(Document doc) throws IOException;
> > > }
> >
> > I'm not sure what the point to this is. The whole point of DocumentHandler
> > is that you don't want to know that it is serializing, constructing a DOM
> > tree, or doing something totally different.
>
> Correct. The whole point of extentions is to add features inheriting the
> old ones.
>
> > I don't know what is gained by
> > making the Serializer interface an extension to DocumentHandler.
>
> because a DocumentHandler, like you said, doesn't have a clue on what
> it's doing. The DocumentHandler caller doesn't care, but you _do_ care
> about where the serialized data is going.
>
> So, like the interface clearly states, a Serializer is a consumer, so
> implements DocumentHandler, but it serializes on an output stream with
> the given output format.
>
> It also allows for DOM serialization.
>
> > > class SerializerFactory() {
> > >
> > > Serializer makeSerializer(Writer writer, OutputFormat format);
> > > Serializer makeSerializer(OutputStream output, OutputFormat
> > > format) throws UnsupportedEncodingException;
> > >
> > > }
> >
> > I'm with Assaf Arken that I would like to see a registerSerializerFactory
> > method on Serializer. The concept of the SerializerFactory is good.
>
> Good.
>
> Stefano.