Hi Ian,
I'll throw out a couple of comments here. The Translators
(as the framework is referred to internally) have proven very effective in
several cases and have withstood alot of teams picking them up
and reusing them. There are two weaknesses here. The first is the level of
documentation (but a nice contributor took the effort of providing
some documentation for this framework: http://www.eclipse.org/articles/Article-WTP-Persisting-EMF/persisting.html ).
I tend to think the framework is relatively straightfoward if you have a
basic knowledge of EMF, but not all people may share my belief in this regard.
The second risk is that the translators are not published API in WTP, and as
such are not guaranteed to be stable from release to release. I am not currently
aware of any plans to make them API for 1.5, so the earliest this might be the
case would be the next formal WTP release after 1.5.
One thing that may or may not be clear is that the
Translators provide integration between SAX, DOM, and the SSE models. The
separation between the rendering technology (SAX, DOM, SSE) and the programmatic
mapping (the Translator subclasses) is inherent in the design. This means that
you can use Translators for synchronizing a plain DOM or integrate them with the
SSE editor. Or for more advanced situations where you're not doing active
editing or synchronization of the EMF model, you can use SAX instead. When
coupled with the UIContextDetermination extension point in JEM
(org.eclipse.jem.util), you can construct a nice piece of adaptive software that
makes the correct decision about which renderer to use transparently (for
instance, in a headless mode, you probably just want SAX whereas in a UI
environment you probably want the full fledged SSE version).
Building a translator mapping which describes an existing
XSD schema is also fairly simple. You could dig through the classes for managing
the WTPModulesResource (in org.eclipse.wst.common.componentcore.internal.util)
and also WTPModulesTranslator (same package) for examples.
Again, I think that available resources was the
determining factor in making these pieces formal API. Perhaps as part of your
efforts to pick these pieces up, you might consider providing some better
documentation around these classes and proposing a patch for what the first cut
of API should look like?
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools
Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
[EMAIL PROTECTED]
Monday, January 30, 2006 7:06 PM
To: "Craig Salter" <[EMAIL PROTECTED]>, "General discussion of project-wide or architectural issues." <[email protected]>
cc: Ed Merks <[EMAIL PROTECTED]>
From: "Ian Trimble" <[EMAIL PROTECTED]>
Subject: RE: [wtp-dev] JSF Tools Project: synchronizing EMF-SSE
To: "Craig Salter" <[EMAIL PROTECTED]>, "General discussion of project-wide or architectural issues." <[email protected]>
cc: Ed Merks <[EMAIL PROTECTED]>
From: "Ian Trimble" <[EMAIL PROTECTED]>
Subject: RE: [wtp-dev] JSF Tools Project: synchronizing EMF-SSE
Craig,
Thanks
very much for the response, and you didn't bore me (maybe try harder next time?
:-) ). This was just the sort of response I was looking for. Basically we just
wanted to know if we were heading into treacherous territory, since we saw
evidence of alternate synchronization approaches. From what we've seen so far,
the EMF-SSE approach works very well for us.
I
appreciate your two cents and agree with you about where a generic reconciler
belongs; I also fully understand time and energy being in short
supply.
Thanks
again,
- Ian
P.S.
Anyone else have any observations or comments they'd like to share about EMF-SSE
synchronization? All information is much appreciated as we explore this area for
the JSF Tools sub-project.
-----Original Message-----
From: Craig Salter [mailto:[EMAIL PROTECTED]
Sent: Monday, January 30, 2006 3:09 PM
To: [EMAIL PROTECTED]; General discussion of project-wide or architectural issues.
Cc: Ed Merks
Subject: Re: [wtp-dev] JSF Tools Project: synchronizing EMF-SSE
Ian,
There's nothing 'wrong' with the EMF-SSE approach (AFAIK) it was just something we didn't make use of for the historical/dependency related reasons mentioned below. Now I will bore you with some history ;-)
The XSD model was developed (by Ed Merks) in open source before the EMF-SSE code was available. In addition there was a requirement to make the XSD model very stand-alone .... so even if EMF-SSE was available I'm not sure if Ed would have tightly coupled it with SSE. The WSDL model was designed to be as similar to the XSD model as possible in order to provide consistent API and implementation (since these models are often used together). These models are capable of synchronizing with a generic DOM. Editor developers can use a thin SSE aware layer of code to notify the model when a DOM node is updated ... other than the notifications there are no SSE dependencies required.
If you want my 2 cents (and you might not) I think a generic EMF-XML reconciler should reside in the EMF/EMFT project (basic SAX->EMF and DOM<-->EMF) and we should provide an SSE aware layer on top of this in WTP. Of course this requires time and energy ... which we are in short supply these days.
thanks
Craig
Craig Salter
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM
Phone: (905) 413-3918 TL: 969-3918 FAX: (905) 413-4920
Internet: [EMAIL PROTECTED] Notes: Craig Salter/Toronto/[EMAIL PROTECTED]
"Ian Trimble" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]01/30/2006 04:14 PM
"[EMAIL PROTECTED]" and "General discussion of project-wide or architectural issues."
"[email protected]" <[email protected]>, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> [wtp-dev] JSF Tools Project: synchronizing EMF-SSE
As we continue to work on the JSF Tools Project, we have been exploring the use of an embedded StructuredTextEditor (of XML "flavour") in a multipage editor where all pages but the StructuredTextEditor use an EMF model. We have worked up a very basic prototype using the "EMF2DOMSSE..." classes from the XML Core plugin. Things are working, life is good.
Yet we have also explored EMF-SSE synchronization in other places in WTP, and have seen that the XML Schema editor and the WSDL editor do not use the "EMF2DOMSSE..." classes, and so we are left wondering why this is so.
Are there perhaps known issues with the "EMF2DOMSSE..." classes? Does the approach scale sufficiently well? Is this approach to be avoided for some reason, or is it perhaps the suggested way to synchronize EMF and SSE models? Are there certain, known cases where one approach may be better than another? Am I asking too many questions?
Thanks in advance for any insight,
- Ian
------------------------------------------------------------
Ian Trimble
JDeveloper Group
Oracle Corporation Canada Inc.
Office: (250) 954-0837
Email: [EMAIL PROTECTED]
Web: http://www.oracle.com
------------------------------------------------------------
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies.
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
