RE: dom loading in Barracuda - proposed change

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