RE: dom loading in Barracuda - proposed change

Hi Christian,

At 05:46 PM 10/6/2003 -0400, you wrote:
>1. simplify the DOMLoading interface like this: (Jake's request)
>
> > 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
>...
> > Also notice that there are no methods taking ViewCapabilities.
>
>I can't really think of any objections to doing this, because as you say -
>its only going to implement those who have written their own DOMLoader
>implementations, and that's probably not  very many people. My question here
>is "are there any other changes beyond those I've just listed above" (I
>don't think so, but I want to be sure).

Well, the, the stuff I listed above implies removing....

public void setDefaultDOMFactory(DOMFactory df);
public void registerDOMFactory(DOMFactory df, Class clazz);
public void deregisterDOMFactory(Class clazz);

I have argued that these are implementation details.  Additionally, I have 
changed two of the above methods in DefaultDOMFactory, where they are 
implemented,  to be...

public void registerDOMFactory(DOMFactory df, String key) { ... }
public void deregisterDOMFactory(String key) { ... }

The reason for that is to add support for registering dom factories against 
both class names and document paths.  The old way was XMLC-centric in that 
it assumed Documents would be loaded from a wrapper class the way XMLC 
works whereas pretty much every other DOM implementation only supports 
loading Document's from a document path (path to a file, whether absolute 
system file path, a path within a webapp, or a path within a 
classloader).  Anyway....

Now, it is arguable that we might want to have these methods in all 
DOMLoader implementations which, actually, would allow for continued 
support of <dom-loader> and <dom-loader-register> in the 
DefaultApplicationAssembler since it counts on all DOMLoader's to have 
these methods.  The question is, are these methods really just 
implementation details or are they important enough that all 
implementations should support them?  I'm teetering on this question right 
now and wouldn't have too much of a problem if you said that you'd like to 
force implementation of these methods in all DOMLoader 
implementations.  Any further thoughts?

Jake