---- On Mon, 15 Nov 2010 00:45:04 -0800 Tudor Girba wrote ----
Hi,
Thanks for this nice overview. I am happy that XML handling gets a bit more traction in Smalltalk :). I took a quick look and your XMLPluggableElementFactory sounds quite interesting, and it's great that it supports namespaces.
Regarding Opax, your analysis is not quite right.
- You do not need to subclass the OPOpaxHandler.
Really? So if I have a pre-existing SAX parser, say SVGSAXParser, there is a way to make it support Opax-like functionality without changing its superclass to be that of OPOpaxHandler?
- The goal of Opax is not to replace DOM, but to enhance SAX. It's true that at the moment it still creates a tree, but this should be changed to make it optional. The original idea of Opax was to dispatch everything, including the factory decision to the Element, but the implementation remained behind the wishes.
To be perfectly honest with you, I did not before nor do I now fully understand what Opax is supposed do. I understand that at the very least it involves mapping elements in an XML document to different kinds of objects, but how it is ultimately supposed to go about doing this remains unclear and appears to still be in flux.
- Opax is tiny: 3 classes + 4 test classes
True, but it takes up two top-level class categories and still adds more weight to the package, and by your own admission it stands to only get bigger.
- OPGenericElement should simply be made a subclass of XMLElement, and we would have the compatibility we would need.
Right, but then it would be a DOM node, and you said you wanted Opax to avoid DOM, or at least the DOM parser.
- I do not see the reasons why DOM should be preferred to SAX. The problem with DOM is that it always creates XML elements :). When you have large XML files, you often do not want to load them, but just to process them directly. This is the goal of SAX, but then SAX is procedural. Opax should be used to transform SAX into an object-oriented handling.
So the goal is something that only produces objects for certain portions of a document, but ignores the rest? I think this could be better built on top of the DOM parser, perhaps as a partial DOM parser.
Instead of removing it, I would suggest a different approach. Let's make it focus on the SAX parsing:
- We could easily get it to use the XMLNodeFactory
- We could subclass OPGenericElement from XMLElement.
I think an approach that used more metaprogramming and dependency injection rather than inheritance would be better. Maybe something that uses reflection to query injected classes to be used for elements and then fills their instance variables based on the names of those variables and the names of the child elements and attributes that the elements the class has been mapped to contain. In other words, you wouldn't need to subclass OPGenericElement OR XMLElement; just have instance variables in the injected class with names matching, roughly, the attribute and child element names of the elements the class has been mapped to. You could also support explicit conversion instructions. For example, something that could be told to map "timestamp" elements to the DateAndTime class and to convert their content using fromString:.
In any case, regarding packaging, I would definitely be in favor of splitting XMLSupport in multiple packages.