RE: dom loading in Barracuda - proposed change

All done and in CVS (although I received no barracuda-commit 
email???).  Report any problems.  I don't foresee any.

For users, make sure you change any cases of stuff like this:
Document page = 
DefaultDOMLoader.getGlobalInstance().getDOM(HelloWorld1HTML.class, 
vc.getViewCapabilities());

To this:
Document page = 
DefaultDOMLoader.getGlobalInstance().getDOM(HelloWorld1HTML.class, 
vc.getViewCapabilities().getClientLocale());


The DOMLoader doesn't take a ViewCapabilities argument anymore.  It was 
redundant with the Locale argument anyway.

Also, for those using the <dom-loader> and/or <dom-loader-register> 
elements in their application assembler files, you will need to switch to 
using the object repository assembler.  See Barracuda's 
sample.object-repository.xml for an example.  I really doubt most were 
using this anyway, so I don't foresee many issues here.

Oh, and I almost forgot the best part.  There is now a JivanDOMFactory 
(along with jivan-1.0rc1.jar in WEB-INF/jars) which can be used as an 
alternative to XMLC.  Note that no localization capabilities are supported 
as of yet in DefaultDOMLoader for templates loaded via a string path (such 
as must be provided for Jivan).  See the Javadoc in JivanDOMFactory for 
information on utilizing it.  You will need to use the object repository 
assembler to declare JivanDOMFactory as the new default dom factory if you 
want to use it (or use Jivan directly if desired...  see 
http://www.jivan.org/ ).

Jake


At 04:27 PM 10/8/2003 -0400, you wrote:
>Hi Jake,
>
> > 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) { ... }
>
>Well, from my perspective I don't mind seeing these go because I don't think
>we use them in any way. And if we did, it seems to me like we could probably
>achieve the same end simply by using the object-repository.xml to configure
>the DOMLoader directly...
>
>So to me it seems safe (and simplest) to drop them.
>
>THoughts?
>Christian
>
>----------------------------------------------
>Christian Cryder
>Internet Architect, ATMReports.com
>Project Chair, BarracudaMVC - http://barracudamvc.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of Jacob Kjome
> > Sent: Tuesday, October 07, 2003 2:19 PM
> > To: [email protected]
> > Subject: RE: [Barracuda] 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
> >
> > _______________________________________________
> > Barracuda mailing list
> > [email protected]
> > http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda