dom loading in Barracuda - proposed change

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