Re: DOMWriter proposed change

While we're waiting for a response from Christian I would go ahead and 
respond and as well.

I should probably note that I'm not specifically opposed to the idea of 
the DefaultDOMWriter closing the output itself, though I do disagree in 
principle. The problem is that the DOMWriter *interface* does not 
specify what the proper behavior is supposed to be. This caused 
confusion for me personally when I needed to create my own DOMWriter 
implementation for our project here at work. I override getDOMWriter() 
in my BTemplateViewHandler to return my own implementation but 
DefaultViewHandler probably assumes the output is automatically closed, 
as in this code:

    this.getDOMWriter().write(doc, vec.getResponse());

 > The problem is that main use-case for the DefaultDOMWriter is...
 >
 > new DefaultDOMWriter().write(dom, vec.getResponse());
 >
 > Here we send the response object to the writer and let the DOMWriter
 > open up the writer or output stream associated with the response.  Since
 > the DOMWriter opens it, it seems like it should close it.  It is also
 > much less klunky than....

Hmm that's true. This use is a little different than the write() methods 
that accept an OutputStream or Writer directly. But does calling 
HttpServletResponse.getWriter() actually *open* the writer or return a 
Writer that is already open? What I mean is, I believe I can call 
getWriter() multiple times and all my output will in fact be going to 
the same, opened, Writer object.

 > Hmm... not too hard, but I'm not sure it gains us anything.  We could
 > even document that it is the responsibility of the implementation to
 > decide how it deals with opening and closing of writers and output 
streams.

I think it should be clear in the interface as to what state the 
implementing classes should leave the writers and output streams in 
because this information would be necessary for classes that use the 
interface to be able to treat it generically without the risk of 
inadvertantly leaving writers/output streams open or having them 
automatically closed when that wasn't expected. Either the interface 
needs to specificy a specific behavior for all the implementing classes 
to follow (currently only DefaultDOMWriter I believe in the Barracuda 
source) or a method should be added to the interface such as 
isLeaveWriterOpen() (or something better) that classes using the 
interface can query.

-shawn

Jacob Kjome wrote:
> At 02:03 PM 10/1/2003 -0600, you wrote:
> 
>> To: [email protected]
>> Subject: [Barracuda] DOMWriter proposed change
>>
>> Hi folks,
>>
>> Jake just sent an email mentioning proposed changes to DOMLoader that 
>> triggered my memory about a change I was thinking of making to 
>> DOMWriter and DefaultDOMWriter.
>>
>> Presently the DOMWriter interface provides various versions of a 
>> write() method (each for different output types). However DOMWriter 
>> does not provide any explanation (in the comments) as to whether or 
>> not the implementing class must close the output objects or not. 
>> DefaultDOMWriter solves this by providing its own "leaveWriterOpen" 
>> option that controls this behavior.
>>
>> My proposal is that we remove the "leaveWriterOpen" option from 
>> DefaultDOMWriter and provide eplanation in the comments of DOMWriter 
>> that implementing class MUST NOT close the output. It should be stated 
>> clearly that it is the responsibility of the class(es) using the 
>> DOMWriter to manually close any output streams.
> 
> 
> Hmm.... I kind of agree with this in principal, but I'm not sure it will 
> make matters any easier for people.  It is just more gruntwork.
> 
> 
>> My thinking behind this is that since a DOMWriter does not open 
>> (create) the output stream, it should therefore also not close it. It 
>> should simply map input in the form of DOM Nodes to the output.
> 
> 
> The problem is that main use-case for the DefaultDOMWriter is...
> 
> new DefaultDOMWriter().write(dom, vec.getResponse());
> 
> Here we send the response object to the writer and let the DOMWriter 
> open up the writer or output stream associated with the response.  Since 
> the DOMWriter opens it, it seems like it should close it.  It is also 
> much less klunky than....
> 
> new DefaultDOMWriter().write(dom, vec.getResponse());
> vec.getResponse().getWriter().close();
> 
> Actually, would we close the writer or output stream here?  It all 
> depends on what goes on internally in the DOMWriter implementation.
> 
>> Any objections to this change? This shouldn't affect any users unless 
>> they are using DefaultDOMWriter or the DOMWriter interface on their 
>> own. Is anyone using these classes directly in their code? To make the 
>> change I would have to make sure I find every instance where 
>> DefaultDOMWriter is used within Barracuda and make sure it does not 
>> expect the output stream to be automatically closed (adding a manual 
>> close where necessary); this shouldn't be too hard.
> 
> 
> Hmm... not too hard, but I'm not sure it gains us anything.  We could 
> even document that it is the responsibility of the implementation to 
> decide how it deals with opening and closing of writers and output streams.
> 
> I'd like to hear what Christian has to say about this since he wrote the 
> DefaultDOMWriter originally and came up with the concept of the 
> setLeaveWriterOpen(boolean) method.  I suspect the reason it was done 
> this way was because it is generally the rare case where one would want 
> to actually leave the writer or output steam open after the call to the 
> write() method.
> 
> I'm not saying I'm completely opposed to this, just skeptical that it 
> would be of benefit.  I'd definitely like to hear more discussion on the 
> topic.
> 
> Jake
> 
>> Thanks,
>> -shawn
> 
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda