new DOMLoader/DOMFactory capabilities

Just wanted to let people know about the functionality I just added to 
DOMLoader and DOMFactory (and implementations).  Here is my recent commit 
message...

Log message:
         *   <p><b>jrk_20030602.1</b> - Added a couple items to the 
interfaces of DOMLoader and DOMFactory.
         *      <p>1. DOMFactory now has getInstance(String docPath) which 
is meant to load the dom directly from
         *      a file rather than a pre-compiled class. This was done to 
support XMLC's deferred parsing, but
         *      is also generic so any other DOM implementation that 
supports loading directly from file could
         *      be used as well. XMLCDeferredParsingDOMFactory was updated 
to support this. See the javadoc
         *      for details.</p>
         *      <p>2. DOMLoader was modified to support the addition to 
DOMFactory by adding getDOMFromFile()
         *      methods analogous to the existing getDOM() methods.  Also 
added convenience getDOM(className)
         *      methods so that you can pass a fully qualified class name 
rather than having to pass a JVM
         *      loaded class. DefaultDOMLoader was updated to support this. 
See the javadoc for details.</p>
         *   <p>These changes shouldn't adversely effect anyone since it is 
doubtful that anyone has, so far,
         *      created their own DOMFactory or DOMLoader implementation. 
So, these changes should be transparent
         *      for most people and provide cool new functionality!</p>


You can now do something like the following....

         DOMLoader loader = DefaultDOMLoader.getGlobalInstance();
         XMLCDeferredParsingDOMFactory lfactory = new 
XMLCDeferredParsingDOMFactory();
         lfactory.setServletContext(this.getServletContext());
         loader.setDefaultDOMFactory(lfactory);

         String docClass = req.getParameter("docClass");
         String doc = req.getParameter("doc");

         Document xmlcdoc = null;
         if (docClass != null) {
             try {
                 xmlcdoc = loader.getDOM(docClass);
             } catch (Exception e) {
                 System.out.println(e);
             }
         } else {
             if (doc != null) {
                 try {
                     xmlcdoc = loader.getDOMFromFile(doc);
                 } catch (Exception e) {
                     System.out.println(e);
                 }
             }
         }

This was code that I tested with based on the ReloadTest.java example from 
XMLC 2.2's Tomcat demo.  Example URL's would look like...

http://localhost:8081/xmlc/ReloadTest?docClass=xmlc.demo.test01HTML
and
http://localhost:8081/xmlc/ReloadTest?doc=page/page01.html


The first case isn't all that new except that the DOMLoader implementation 
does the creation of the doc class so you don't have to, so you can just 
send the String of the class name to the getDOM() method.

The second case is totally brand new and takes advantage of the xmlc 
deferred parsing capabilities of being able to load a document directly 
from a file without the need for pre-compilation.  I can see this being 
used for a Wiki Barracuda implementation!  Any takers on implementing this?

Note that the servlet context was provided to the deferred parsing dom 
factory (this can be done automatically using Barracuda's application 
assembler config cutting the first 4 lines down to just a single line; the 
first line)  .  It used it to extract some <context-param> values to 
provide information about resource paths to xmlc's deferred parsing factory 
(just like XMLCContext does).  You can also set this programmatically, but 
I'd only do that if you were trying to load this outside the context of a 
servlet engine because the paths are OS-specific and you probably don't 
want to hardcode that...unless you provide you own config system to 
abstract this.  The assembler config is much easier to deal with.  The 
context parameters look like this...

   <context-param>
     <param-name>xmlcReparseResourceDirs</param-name>
     <param-value>D:\myclasses\Repository\Enhydra\XMLC_DSF_2003-05-19-2\xmlc\examples\tomcat\res;D:\myclasses\Repository\Enhydra\XMLC_DSF_2003-05-19-2\xmlc\examples\tomcat\res\pkg</param-value>
   </context-param>
   <context-param>
     <param-name>xmlcReparsePackagePrefixes</param-name>
     <param-value>xmlc</param-value>
   </context-param>
   <context-param>
     <param-name>xmlcReparseDefaultMetaDataPath</param-name>
     <param-value>options.xmlc</param-value>
   </context-param>

One very nice thing about context param's is that they can be overridden or 
provided even if they don't exist in web.xml via server-specific 
configuration.  For instance, in Tomcat, I can do...

<Context ....>
     <Parameter name="xmlcReparseResourceDirs" 
value="D:\my\alternate\path\to\resources" override="true"/>
     <Parameter name="xmlcReparsePackagePrefixes" value="pres" 
override="true"/>
     <Parameter name="xmlcReparseDefaultMetaDataPath" 
value="otheroptions.xmlc" override="true"/>
</Context>

See the javadoc for DefaultDOMLoader and XMLCDeferredParsingDOMFactory for 
more info.  Let me know if you have comments or questions.  Localization 
support is not yet enabled for loading documents directly from file.  I 
need to look into what needs to be done to support that.  If you have 
ideas, look at DefaultDOMLoader and make comments or supply patches.

Jake