xmlenc-devel

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

Re: [xmlenc-devel] New XMLOutputter approach

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

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

Well, not init(Writer,String), but reset(Writer,String). The init method is 
now replaced with reset.

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

An XMLOutputter object is rather light, but it initially holds a stack for 
an element depth of 32. It increases with 100% each time (to 64, 128, 256, 
etc.) So the object is heavier if ever used with a deep document.

I've chosen this approach because if ever one deep document is written, then 
it is likely that a document with a similar depth is written at a later 
stage.

Ernst

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

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