Actually there's already a neat way to do this. The JAXM folks already do it to have different classes for SOAPEnvelope, SOAPHeader etc.
The trick is to register a DocumentFactory instance with a specific QName. Then automagically you can use your own factory for different names of elements in your document. The neat thing about this is that it works for any parser (XPP, SAX, DOM) or with general application logic of the form... DocumentFactory factory = new MyFactory(); Document doc = factory.createDocument(); Element root = doc.addElement( "foo" ); Element bar = root.addElement( "bar" ); The org.dom4j.datatype package uses a similar technique to register specific implementations of Element and Attribute classes for different 'types' in a schema. It all works quite neatly. Though as you bring up Bob - using XPaths to denote types is a good idea as well. James ----- Original Message ----- From: "bob mcwhirter" <[EMAIL PROTECTED]> To: "Matthew Sinclair-Day" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, February 11, 2002 9:19 PM Subject: Re: [dom4j-user] Strategies for mapping XML to objects > > Then, I'd probably create a custom DocumentFactory that instantiates > sub-classes of Element based upon namespace/name. > > I think a generic DocumentFactory with a way to register ElementFactory > objects would be a good thing in the general distribution. > > You could also do it with simply using ElementHandlers on the SAXBuilder, > as then you wouldn't have to have the same Element subclass for each > <foo> tag, but could add some context information: > > ie: > > /foo --> MyRootFooElement > > /bar/foo -> MyBarFooElement > > In that case, though, you'd be given the DefaultElement in your ElementHandler, > and you'd have to detach() it, and replace it with your preferred sub-class. > > TMTOWTDI, as the perlmongers would say. > > -bob > > > On Mon, 11 Feb 2002, Matthew Sinclair-Day wrote: > > > On 2/11/02 at 3:47 PM, [EMAIL PROTECTED] (bob mcwhirter) wrote: > > > > > > > > http://castor.exolab.org/ > > > > > > No reason to re-invent the wheel. > > > > > > -bob > > > > > I appreciate the advice but in this case neither Castor or JAXB would be > > appropriate. I probably should have been clearer in the original post, > > but I want the objects to hold onto their XML roots and essentially > > either be opaque wrappers for dom4j or, as I suggested in the post, > > simply extend the default implementation to provide a more specific type > > than the Abstract/DefaultX classes. I think the latter approach is more > > straight forward and would work better for my needs. My question has > > more to do with approach and implementation in the dom4j universe. > > > > Matthew > > > > _______________________________________________ > > dom4j-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dom4j-user > > > > > _______________________________________________ > dom4j-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dom4j-user > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ dom4j-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-user
