15 Nov
2010
15 Nov
'10
8:46 a.m.
The most recent version of XML-Support comes with a factory-based abstraction layer to
customize the node object construction done by the parser. The default factory is just a
number of stateless accessors with names like #elementClass and #documentClass that return
class objects. This class can be subclassed and those messages overridden, and the
subclass can then be instantiated and injected into a DOM parser using #nodeFactory:
before parsing.
However, also included is a node factory subclass named XMLPluggableElementFactory that
can map specific elements to specific element classes based on the name and namespace
information of the elements in question. Here is an example of its use:
doc := (XMLDOMParser on: aStringOrStream)
nodeFactory:
(XMLPluggableElementFactory new
handleElement: 'user' withClass: MyUserElement;
handleElement: 'report' withClass: MyReportElement;
handleElement: 'report' namespaceURI: 'urn:specialReport' withClass:
MySpecialReportElement);
parseDocument.
This is undoubtedly similar to Opax, if not in its approach then certainly in its intent.
I feel, however, that it is superior to Opax in a number of respects and question whether
Opax should remain in XML-Support.
First, the node factory abstraction layer is based on the DOM parser and XMLNode classes,
not the SAX parser and the custom OP*Element classes Opax has added. This means that users
will get back instances of XMLElement subclasses rather than OPGenericElement subclasses,
and those objects will support the entire XMLElement protocol. Second, the pluggable
element factory enables more powerful element/class mapping based not only on the names of
elements but their namespace information as well. Third, the element factory and its test
are both quite small, in part because they do not need to duplicate the functionality of
XMLElement like OPGenericElement does. Fourth, because the element factory is a subclass
of XMLNodeFacory, it can be subclassed further to exert additional control over which
classes the DOM parser should use for other, non-element nodes. Fifth and perhaps most
important of all, the factory approach does not require a specific subclass of
XMLDOMParser to be used; it is injected into a DOM parser by the user, so any DOM parser,
even ones that already exist, can use it without modification. To use Opax, however, a
parser must be a subclass of OPOpaxHandler, which is itself a subclass of SAXHandler. That
means DOM parsers can't be used with Opax at all, and existing SAX parsers can't
use it unless they are rewritten to be subclasses of OPOpaxHandler.
I think Opax should be taken out and made optionally loadable by the Metacello
configuration file. In fact, this should be done regardless of which approach is
preferred, as the package is already quite large and stands to get larger as more is
added. I plan on making XMLWriter a separate but required package, and the test suites
separate but optional packages.
If anyone has any objections, I would like to hear them.