Re: [xmlenc-devel] New XMLOutputter approach

[Ernst de H. <zn...@Fr...>]

Hey Pete,

> What, exactly, does outputter.reset() do? Will it ever be called
> independent of init()? If not, maybe it would be cleaner to instead do:

The idea was that a worker thread could call reset() when it's done and then 
init() when it starts working again. For example when XMLOutputter 
instances are kept in a pool.

> outputter.reset(writer, encoding);
>
> You could also overload it and have outputter.reset() for cases when you
> don't need a different writer or encoding. I guess I'd like to see the
> reuse case be done with a single method call if that makes sense, just
> so people can't forget the reset() or the init().

I see your point. On the other hand I've got another requirement, and that 
is that it must be possible to create an XMLOutputter instance that has no 
Writer associated with it yet. So perhaps we should combine this with your 
suggestion and have:

   XMLOutputter() { ... }               // State: UNINITIALIZED
   XMLOutputter(Writer, String) { ... } // State: BEFORE_XML_DECLARATION

   reset() { ... }               // State: UNINITIALIZED
   reset(Writer, String) { ... } // State: BEFORE_XML_DECLARATION

> I think this was a good idea though. I can envision cases when I'll need
> to write several XML files at once, and this way I can reuse the
> outputter(). (Maybe similar to a database connection or something.)

Exactly. I really look forward to retesting the xmlenc performance with this 
new approach in place!

Regards,


Ernst

-- 
Ernst de Haan
Development Team Leader
Wanadoo Nederland B.V.

    The Lord has truly risen!
    Merry Christmas and a blessed New Year!