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.

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.

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.

Thanks,
-shawn

Jacob Kjome wrote:
> 
> Hi everyone,
> 
> Since we now have a simple viable alternative to XMLC DOM Loading via 
> Jivan, I thought I'd try it out.  I created a new JivanDOMFactory which 
> seems to work nicely.  However, as I was looking at the DOMLoader and 
> DefaultDOMLoader, I noticed some unnecessary complexity (partially my 
> fault).  I'm wondering if anyone would object to a slight change to the 
> interface.  I was thinking of getting rid of any method taking 
> ViewCapabilities as a parameter and any non-getDOM() methods.  This 
> would simplify the interface significantly and keep more 
> implementation-specific methods out of the Interface.  This would make 
> other DOMLoader implementations much easier to create and maintain.
> 
> What I'd like to do is point out the changes to the DOMLoader interface 
> and where these changes affect existing code.  After evaluating that, 
> I'd like to hear your point of view whether this change would cause any 
> pain for existing applications.  So, here are the proposed changes...
> 
> The following methods are now all that exist in DOMLoader....
> 
>     public Document getDOM(String doc) throws IOException;
>     public Document getDOM(String doc, Locale locale) throws IOException;
>     public Document getDOM(Class clazz) throws IOException;
>     public Document getDOM(Class clazz, Locale locale) throws IOException;
> 
> Notice that the getDOM(String) methods now expect a file/URL path to a 
> document rather than being convenience methods to send in a fully 
> qualified class name as they were before (and were only recently added 
> by me).  This has replaced getDOMFromFile(String) that had been added to 
> support dynamic loading of documents in Barracuda-1.2.5.  I don't think 
> this should cause undue pain since it is more likely that people use the 
> getDOM(Class) methods anyway.
> 
> Also notice that there are no methods taking ViewCapabilities.  The 
> reason for this is that we might as well just pass in the Locale since 
> that is all we use the ViewCapabilities for anyway...at least in dom 
> loading; dom writing may be another issue.  The way this affects 
> existing code in Barracuda is to change this:
> Document page = DefaultDOMLoader.getGlobalInstance().getDOM(clazz,  
> vc.getViewCapabilities());
> to this:
> Document page = DefaultDOMLoader.getGlobalInstance().getDOM(clazz, 
> vc.getViewCapabilities().getClientLocale());
> 
> Not too tough, if you ask me.
> 
> 
> The other methods that have gone away from the DOMLoader interface are...
> 
>     public void setDefaultDOMFactory(DOMFactory df);
>     public void registerDOMFactory(DOMFactory df, Class clazz);
>     public void deregisterDOMFactory(Class clazz);
> 
> These seem to me to be more implementation-specific.  I've left modified 
> versions of them in DefaultDOMLoader, but I think the DOMLoader can live 
> with the getDOM() methods alone.  I changed these methods in 
> DefaultDOMLoader to take a String instead of a Class to key particular 
> DOMFactory's.  This makes it easier to support the keys as being either 
> class names or document file paths which allows for registering 
> individual files to be loaded by, say..., the JivanDOMFactory and 
> individual class names by one of the XMLC dom factories.  Before, this 
> was only possible for XMLC-based classes.
> 
> 
> Now, besides the previously described necessary change to existing code 
> in order to be compatible with the new DOMLoader interface, I had to 
> comment out all the dom loader stuff in DefaultApplicationAssembler.  
> I'm not sure how many people out there currently use the <dom-loader> 
> and/or <dom-loader-register> stuff in your application assembler files.  
> I suspect not too many.  Of course, this functionality has already been 
> superceded by the object repository assembler anyway.  So, the 
> functionality is still there (in an even more flexible form), it just 
> would no longer be supported in the DefaultApplicationAssembler.
> 
> 
> Basically, if people have been using the basics for dom loading, I don't 
> see this change as affecting people much at all.   I hope that is the 
> case.  Please let me know your opinion on what I've described above and 
> tell me whether you think this change is acceptable or not.
> 
> Jake
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda