Cart
[Home] [By Thread] [By Date] [Recent Entries]
Forwarded for David Brownell: [ My posts to this list generally get swallowed somewhere, so I expect to need to forward this manually ... ] Tyler Baker wrote: > > Michael Kay wrote: > > > Actually I'm not sure subclassing Element with a "semantic" > > subclass, e.g. a business object such as Invoice, is the > > right approach, because you get a clumsy class heirarchy, > > and you invite the user to override methods inappropriately. The API to that feature is subject to change, more than most other parts of the library. For example, it's not yet aware of namespaces. We see such subclassing as only one of several tools that need to exist. (Any tool can be misused!) One thing that comes from subclassing is the ability to modify the tree construction dynamically. You can optimize in-memory representations easily -- e.g. removing ignorable whitespace and things like redundant representations of data (cutting memory use by quite a bit!). Also, anyone who's really manipulating text will need more than DOM should even think of supporting. I think it'd be generally true that the semantic model that is used by an application would not always conform to the XML structure, exposed by DOM. An example we've used is that of a 3D spreadsheet. The internal representation will need to be highly optimized for most things; tables will be either dense or sparse arrays, with "slice" operations, for starters. It could be fine to have such an optimized object "boxed" inside a DOM document, minimizing the need for document-specific navigation APIs and maximizing code reuse. No need to have an XML-oriented representation of that core data also lingering around -- that's needed for externalization, period. > > I'd prefer to have the Element contain a "userObject" > > pointer to the business object. Such a delegation approach is necessary in any case, since it's important to integrate into frameworks that already define their own base class. Is it sufficient? Hmmm ... almost certainly not, IMHO. Even so, it's on the roadmap. > I pretty much never ever subclass anything for typing purposes > except as a code reuse policy. I have already learned the hard > way that this sort of approach builds highly inflexible and > highly inefficient systems. It also builds flexible and efficient ones. One uses the right tool for the problem, and sometimes subclassing is that tool. > Every major Java ISV out there seems to get > this other than SUN who still seems to prefer the subclassing > approach in their designs. Remember that this functionality is documented as "experimental" and subject to change ... also, that quite a few systems have had real success with this particular style of subclassing. Many XML related ones too! COINS, IBM's XML4J, and more. The Raven editor uses this (and other techniques), and a number of HTML display packages too. I was intrigued by the statistics Steve Withall presented at the XML Developer's conference, showing that by far the bulk of the customization code was associated with elements. (See his XML Testbed, on "xml.com"!) > Maybe this is for some potential > purpose of vendor lock in. Who really knows. I do, I do!! There are no such dark motives lurking here. - Dave Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
