Assaf Arkin wrote:
>
> I like it.
I like the design too. Well balanced.
> I think init() should be aptly named setOutputFormat(), with a guarantee
> that doing either a setOutputFormat() or setOutputStream() will
> re-intialize the serializer.
Hmmm, some thoughts:
the proposal follows the "common end mode": you create the serializer
for a given output stream (I clearly see this since Scott is probably
thinking of System.out) and reuse it for every document.
Applying symmetries, you the "common start mode" where you would create
the serializer for a document and reuse it for different streams. Kind
of useless, I agree.
But there is another mode, which is not hubbed on input nor output, but
on code. For servlets, you have one document and one stream. None of
them can be reused.
No suggestions, just asking for comments: do you think we should have a
more general reset() with no fixed ends (no document, no stream reuse)?
Usually, in servlets I would create a new serializer everytime to avoid
concurrency problems (reusing a serializer could cause incredible
deadlocks), but maybe the code is so simple that we could reuse() them
(even if I don't count on it).
Comments on this?
> I would rather use the names asDOMSerializer() and asDocumentHandler()
> because you are returning a different view of an already created
> serializer, not creating a new one (even though each of these objects
> could be separate).
I like this more, too.
> Other than that, +1 for me on all interfaces proposed.
>
> One question, though. I see people getting confused with the name
> BaseSerializer assuming that all serializers must extend it, when in
> fact it's very specific to XML/HTMLSerializer. I'm looking a name that
> will convey being a parent class (and abstract), but not one that people
> should be looking to extend or construct. And idead?
AbstractSerializer?
AbstractMarkupSerializer?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche