Re: [xmlenc-devel] New XMLOutputter approach

[Pete C. <pe...@fi...>]

Hi Ernst,

> 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.

OK, I didn't think of this. It's a potentially useful scenario.

> 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 like this. I would normally use the XMLOutputter(Writer, String) form.
But the XMLOutputter scenario discussed above would prefer the
no-argument constructor.

I also like the overloaded reset approach. I think reset() with no
arguments sets the member variables for Writer and Encoding to null,
right? In other words, it doesn't leave them as is for potential reuse.
So it requires a call to init() at a later time (useful in the pooling
scenario).

On a side note, XMLOutputter is a rather lightweight object, right?
Someone might pool the thing for reuse, but I don't think you'd gain the
same kind of benefit as you would from, say, pooling database
connections. I think the more likely reuse scenario would be to write
out several XML files in quick succession, perhaps when a user logs out
or his session times out on the server, or when a client-side program exits.

Gratefully,

Pete Cassetta
pe...@fi...

-------------------------------------------
Fingertip Software
433 Kitty Hawk Rd., Suite 216
P.O. Box 2487
Universal City, TX 78148

Orders:  (800) 209-4063 -or- (210) 659-6832
Support: (210) 659-2532
Fax:     (210) 659-8870

http://www.fingertipsoft.com
-------------------------------------------