XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On 11/30/05, Kevin Y. Kim (Lists) <kykim_lists AT mac.com> wrote:
> Hey all,
>
> Is there someone who's willing to share/provide a good example of
> Element subclassing
> and a custom node factory?  Conceptually, I think it's what I want to
> do based on the
> tutorial, but I'm not sure how to begin.
>
> Basically, I am using Xom to parse out XML information and create some
> custom objects.
> It seems to me that I could save some work by merging my custom objects
> with an Element
> subclass.  I think that once I have my subclassed Elements, I'll just
> detach() them
> and pass them around my application.  It would probably make the output
> XML easier too.
>

A very minimal example is from a prototype xom-based soap stack:

http://cvs.sourceforge.net/viewcvs.py/smartfrog/projects/alpine/prototype/M32/src/java/org/smartfrog/projects/alpine/om/soap11/Soap11NodeFactory.java?view=markup

Every element is created as a subclass of ElementEx; this adds java1.5
features (QName integration, java1.5 iterators)

http://cvs.sourceforge.net/viewcvs.py/smartfrog/projects/alpine/prototype/M32/src/java/org/smartfrog/projects/alpine/om/base/ElementEx.java?view=markup

explicit subclasses   include things like the soap header
http://cvs.sourceforge.net/viewcvs.py/smartfrog/projects/alpine/prototype/M32/src/java/org/smartfrog/projects/alpine/om/soap11/Header.java?view=markup

Oh, every class also implements a validateXML interface that I use
down to get things to validate themselves; this lets me declare
validity logic in code rather than XSD. Normally procedural
specifications are considered worse than declarative ones, but here I
make an exception.