[jdom-interest] integration by derivation with JDOM classes

[philip.nelson at omniresources.com]

Yeah, I think Matt is on the right track.  How much does your business
process have in common with a JDOM Element?  Not much I would have to guess.
Make your application classes do what makes sense and use JDOM to serialize
to xml.


> What I fear is that JDOM classes may not be designed for such an
>"integration by  derivation" approch, and that this solution may be
>risky...
>
> any opinion ?

Risky only in that there is an inherent mismatch between what a Business
Process application is and what an xml document is.  If you are attracted to
using JDOM because of the built in tree structure, you will probably find
that the xml model, with all it's checks and requirements, will not be
terribly useful in your application.  Just use the Collections api with your
own classes, and then define a comfortable location to put some sort of
toXML method or helper class function.

-----Original Message-----
From: Matthew MacKenzie
To: franck.delahaye at akazi.com; jdom-interest at jdom.org
Sent: 10/29/01 9:47 AM
Subject: RE: [jdom-interest] integration by derivation with JDOM classes

Franck,

The JDOM classes will work fine for what you are talking about, but
there is another option for you.  What I have done in a couple products
is to use JDOM for marshalling and unmarshalling; basically modelling
out the classes for the application as I would like to see them, and and
applying JDOM after the fact.  For example, I did something recently
that looked a bit like this:

interface Message {
	public Element toXml();
	public void load(Element el);
}

class Person implements Message {
	public Person() {}
	...
	public Element toXml() {
		Element e = new Element("Person");
		e.addContent(getAddress().toXml());
		...
	}

	public void load(Element e) {
		...
		Address a = new Address();
		setAddress(a.load(e.getChild("Address")));
	}
}

A more flexible model is the "Builder/Outputter" model that JDOM uses.
This would allow you to use something other than JDOM in the future if
you needed to, say, load business processes from something that is
non-XML.  I've gone that way successfully as well.

Regards,

Matt

 

-----Original Message-----
From: jdom-interest-admin at jdom.org [mailto:jdom-interest-admin at jdom.org]
On Behalf Of Franck Delahaye
Sent: October 29, 2001 7:38 AM
To: jdom-interest at jdom.org
Subject: [jdom-interest] integration by derivation with JDOM classes


Hy everybody,
I'am new to this list and so to JDOM too.
we are currently prototyping a Business Process modeler.
It is implemented using Java/JDOM.
 After the first protoyping phase (quiet fast with JDOM), we came to
the conclusion that the best base architecture for the  modeler is to
derive our Business Process classes from the JDOM standard  classes (
particularly the Element and Attributes classes), like this:
  a Business Process --> is a --> Document with a "process" root Element
  a Business Process Graph --> is a --> "graph" Element child of a
"process"  Element
  ...

 The idea is then to implement Business Process modeling specific
methods and  checks in the derived classes, and leave the door open to a
direct JDOM  manipulation for other kind of application such as online
documentation generation, ...

 What I fear is that JDOM classes may not be designed for such an
"integration by  derivation" approch, and that this solution may be
risky...

 any opinion ?

 Franck
 email: franck.delahaye at akazi.com



_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@you
rhost.com