Re: [Xpipe-developers] draft Java implementation of XComponent for comment

[Sean M. <sea...@pr...>]

David,

Thanks David. I hope to get a chance to look at your work
this coming week.

The bad news is that I have not got the work done on XPipe
that I wanted to this week so the roadmap has slipped by a week.

The good news is that XPipe will be a subject at two upcoming
XML events. It will no doubt creep into the panel discussion
on Web Services to be held at the inuagural meeting of the
Irish XML SIG - Wed Feb 8th in Dublin (http://www.xmlireland.com).

XPipe is the subject of a talk I will be giving on Tuesday, 12 February
in New York Details available from Walter Perry (wp...@fi...).

regards,
Sean

At 13:36 20/01/2002 -0500, David Starr wrote:
>I've placed a draft Java implementation of XComponent at
>http://www.starrconnect.com/xpipe/JavaXComponent.zip
>
>Structurally the model parallels Sean's python model.
>
>For serialization/deserialization the system uses JDOM.  I had considered
>using one of the many data binding frameworks, but I don't know of any that
>support RNG.  From a maintainability standpoint I'd rather take the pain of
>hand coded serialization than maintaining parallel schemata.  Although that
>may just be me.
>
>Each class implements a toJDOM method that returns a JDOM element.  The
>XComponent object's toXML method uses JDOM's XMLOutputter to generate XML
>text.  A future refactoring enhancement will be to derive each object in the
>model from some superclass that implements a single toXML so that each can
>generate an XML fragment.
>
>Each class also implements a toString for debugging purposes.  Coming will
>be equals and hash methods for those classes that need them.
>
>Error handling is not really addressed yet.  I'll take care of this soon.
>
>For discussion, I have also subclassed XComponent with three classes
>JavaXComponent, XSLTXComponent, and PythonXComponent.  There is a
>XComponentFactory that can be used to create the correct XComponent object.
>It is my intent to be able to invoke the XComponent directly through a
>process() method.  I have implemented this for the XSLTXComponent, but the
>other two will take some work.  To process an XSLT XComponent, all you'd
>have to do is:
>
>         XComponentFactory fact = new XComponentFactory ();
>         XComponent xc = factory.getXComponent ("xc0.xco");
>         xc.process ({in.xml; out.xml});
>
>Of course, if all this works, the system won't be required to extract code
>and other resources won't need to be extracted to disk to execute or test
>XComponents.  Thoughts?
>
>If others like this approach I'll keep moving on it.  First building a
>classloader to load the code for Java XComponents, then moving on to the
>Jython case.
>
>David
>
>David Starr
>18 Winthrop Terrace
>Wayland, MA  01778
>(508) 358-2975
>da...@st...
>
>
>_______________________________________________
>Xpipe-developers mailing list
>Xpi...@li...
>https://lists.sourceforge.net/lists/listinfo/xpipe-developers

http://www.propylon.com