[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] DOM Facade work
|
Michal,
just a short response:
I am OK with also extending Import etc. from ExtensibleElement - eventually
we have to do this anyway when we move up to be fully 2.0 compliant.
Concerning the XMLSerializer I also have no objections.
However, I dont understand your "one direction" comment. In that recipe
that I posted some time ago I have the xx2XML and XML2xx in the xxClass
(substitute xx by Receive etc.), so that should be bidirectional, and I
would actually prefer that solution instead of some temporary.
Or am I misunderstanding something here ?
Cheers
Simon
Simon Moser, M.Eng. Mail: IBM Deutschland
smoser@xxxxxx Entwicklung GmbH
Team Lead BPEL Editor / .com Vorsitzender des
Websphere Integration Phone: Aufsichtsrats: Johann
Developer +49-7031-16-4 Weihen
Dept. 4722, Bldg. 71032-01, 304 Geschäftsführung: Herbert
Room 086 Fax: Kircher
Websphere Solutions and +49-7031-16-4 Sitz der Gesellschaft:
Services 890 Böblingen
IBM Deutschland Entwicklung Registergericht:
GmbH Amtsgericht Stuttgart, HRB
Schönaicherstr. 220, D – 243294
71032 Boeblingen
Michal
Chmielewski
<michal.chmielews To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org cc
Subject
04/10/2007 12:36 [bpel-dev] DOM Facade work
AM
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
Bruno,
Any news on that ?
Simon,
I've actually taken a look at some of the code that's in there in
BPELWriter trying to fix an indent problem on save of the process map.
Turns out there some strange settings in JDK5 on the transformer
defaults that can only be overwritten via bootclasspath settings ... I
managed to locate this bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5064280
So I replaced the code in there (10 lines or so) with the xerces
specific XMLSerializer way of saving things (which is in an eclipse
plugin, so isolating that from the JDK issue)
Regarding the DOM facade, we derive almost everything from WSDLElement
ultimately (via ExtensibilityElement) - there were a few EMF objects
that did not do that (like import for example and a couple of others). I
had made the change to derive these from WSDLElement too just so that I
can have the getElement() setElement() capability on all of our model
objects.
Now I reckon there is already some capability in that layer to reconcile
changes which are applied to the model to the DOM elements present
within. I looked at the code down low and it seemed that all the parts
around moving, attaching,detaching, etc. seem to be there. The only
thing that remains to be written I think is some way to flush the
current state of the EMF object to the DOM element it wraps when the EMF
objects changes. This is not as nice a facade as it could be (since it
is one directional) ... but it would serve our immediate purpose of
preserving some of the nodes which are currently destroyed during
reading/writing.
Thoughts ?
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
