Sean Kelly wrote:
>
> Blech. Are static methods allowed in the DOM specification (and are
> they language independent)?
They are but not at the IDL level. It has to be done at the language
binding level. BTW we've been told it's a known pb with IDL!...
> I'd love to see a singleton or static
> factory class that yields useful objects like a Document or the
> DOMImplementation.
I'm with you there! As a matter of fact, when I first introduced the
DOMImplementation, in one the Working Drafts of DOM Level 1, it was
exactly that. But it was changed to an interface later on the basis that
it wasn't applicable to IDL.
> Care to shed some light on your proposal for Level 3?
Sure, I thought about many different possibilities, some much more fancy
than others, but decided to go for something as simple as possible. It
would only be part of the Java binding and could be something like this
(please note that it's from a WD which hasn't been reviewed by the DOM
WG, and which isn't even public yet, so it's as far from being settled
as it can be!!!) It's very similar to what JAXP does for parsers.
--------
The following defines a Java class called DOMImplementationFactory which
provides with a static method to get a reference to a DOMImplementation.
The actual class to be returned by getDOMImplementation can be specified
by the application or the implementation, depending on the context,
through the Java system property "org.w3c.dom.DOMImplementation". In
addition, an implementation can provide its own version of this class,
with the same class name and package name, in order to set the default
name to the desired value.
package org.w3c.dom;
public abstract class DOMImplementationFactory {
// The system property to specify the DOMImplementation class
name.
private static String property =
"org.w3c.dom.DOMImplementation";
// The default DOMImplementation class name to use.
private static String defaultImpl = "NO DEFAULT IMPLEMENTATION
SET";
/**
* Returns a DOMImplementation
**/
public static DOMImplementation getDOMImplementation()
throws ClassNotFoundException, InstantiationException,
IllegalAccessException, ClassCastException
{
// Retrieve the system property
String impl;
try {
impl = System.getProperty(property, defaultImpl);
} catch (SecurityException e) {
// fallback on default implementation in case of security pb
impl = defaultImpl;
}
// Attempt to load, instantiate and return the
implementation class
return (DOMImplementation)
Class.forName(impl).newInstance();
}
}
With this, the first line of an application typically becomes something
like:
DOMImplementation impl =
DOMImplementationFactory.getDOMImplementation();
Issue Level-3-Java-Bootstrap-1:
Should this provides for handling more than one implementation at a
time?
Issue Level-3-Java-Bootstrap-2:
Should this be even simpler and force the implementation to provide this
class (and not necessarily rely on any system property)?
---------
Keep in mind that there are two very different contexts to consider. One
is where the application is in control, it's "linked" to one or more DOM
implementations and may want to choose which one to use. The other is
where the implementation is in control, the application is like a
plug-in, and can't choose which implementation it wants to use, it just
needs a way to get a hold on the hosting implementation.
Additional fancy features that I considered are things like a discovery
mechanism, a way to select the implementation based on a set of
requested features, etc...
> > I wish JAXP addressed this problem but it doesn't either. :-(
>
> Thanks a lot, W3C! :-(
W3C isn't the one to blame for JAXP. Sun along with the JCP participants
are.
--
Arnaud Le Hors - IBM Cupertino, XML Technology Group
