Simon D Moser wrote:
In the future I see the following 3 easy steps of 'binding' source view
(structuredTextEditor) and the DOM model:
1) create DOM model;
2) initialize the source view;
3) set the source view model to the DOM model created above.
At the moment StructuredTextEditor doesn't allow changing it's model (the
only method that changes the value of the fStructuredModel field is
deprecated private setModel(). So, we'll probably have to extend
StructuredTextEditor for our needs.
The visual editor has a concept of a shared model that it shares
between various editor instances. That is currently in
org.eclipse.bpel.common.ui.editmodel
One of the items in the editor the ability to re-load a file if someone
had changed it (a resource changed event). If the text editor is a
viewer then it ought to be able to respond to these types of events as
well and be able to set the (new), potentially, re-read model from
disk. Just something to consider.
Generally yes. I would think that a branch is the better solution here. Let
me find out how to create one (we can apply the source tab patch on the
branch right away).
Michal, do you know how this works by any chance?
I think we just create a branch from CVS on the trees to which we can
commit to. So it should be pretty painless. But have not done it in the
eclipse.org context yet :-)
My gut says that using two different DOMs is not that great. And I think
that such code shouldn't be too easy to maintain, especially for
So what's really so special about the SSE DOM. Is it that it is a
little more forgiving about syntax, unclosed elements, etc. ? Is SSE
DOM a superset of regular DOM ?
newcomers.
(I was really confused by saying "this code [in WSDLResourceImpl] looks
just
redundant.", you noted it right :) )
But the completely grey area for me is: can we use only SSE DOM? Can we
When I say "DOM" I generally refer to XML DOM, the lowest level W3 XML
DOM thing. Is SSE DOM not an XML DOM ?
use BPEL validator to help us identify problems like malformed XML?
The validator uses the model code to read the BPEL process. So it will
behave the same way as the BPEL Editor does today.
The point is, validation, especially the final ones, and deployment, do
require editor-less reading of the source. That should be excluded as a
result of this thinking here.
Good question, and honestly I dont know. I dont know the differences
between the SSE and regular DOM yet. For the Validator question, Michal
might be able to answer this.
Cheers
Simon
Simon Moser, M.Eng.
Websphere Integration Mail: IBM Deutschland Entwicklung
Developer Development smoser@xxxxxx. GmbH
Team Lead BPEL Editor com Vorsitzender des
Dept. 4722, Bldg. Phone: Aufsichtsrats: Martin Jetter
71032-01, Room 086 +49-7031-16-43 Geschäftsführung: Herbert
Websphere Solutions and 04 Kircher
Services Fax: Sitz der Gesellschaft:
IBM Deutschland +49-7031-16-48 Böblingen
Entwicklung GmbH 90 Registergericht: Amtsgericht
Schönaicherstr. 220, D – Stuttgart, HRB 243294
71032 Boeblingen
"Tishkov, Vitaly
V"
<vitaly.v.tishkov To
@intel.com> Simon D Moser/Germany/IBM@IBMDE
cc
05/30/2007 12:40 Michael Illiger2/Germany/IBM@IBMDE
PM Subject
RE: Our Dom Facading Knowlegde
Hi Simon,
@step1 you wrote: If I'm correct with the way WSDL editor build models
(see
above), then we'll have to use Editor (actually, StructuredTextEditor) to
build DOM tree. If you apply my patch I sent to the list a few days ago
(see message "adding source view - patch #1"), then you have the DOM tree
built. We'll need to refactor code which builds BPEL tree from the DOM
tree. As far as I understand, BPELReader can be eliminated this way.
==> Agreed. As I said before, I think we can start from there.
OK, let's start from there.
In the future I see the following 3 easy steps of 'binding' source view
(structuredTextEditor) and the DOM model:
1) create DOM model;
2) initialize the source view;
3) set the source view model to the DOM model created above.
At the moment StructuredTextEditor doesn't allow changing it's model (the
only method that changes the value of the fStructuredModel field is
deprecated private setModel(). So, we'll probably have to extend
StructuredTextEditor for our needs.
@1. Do we need to separate "core" and "view" functionality in BPELEditor
sometimes in between these steps?
==> Not sure what you exactly mean by that. What exactly is "core", what
is
"view" ? Assuming that "core" is loading etc, there might be a need to
seperate some of this (which might go in line with the refactoring that we
have to do in order to add the source view properly, correct ?. Either
way,
I think I need to understand your question better.
Yes, your assumption is correct. Sorry for being not clear.
I'll send my proposal for separating "core" and "view" in another message.
@2. Is it possible to do our task with the "separating" task in parallel?
Do you expect merge problems later?
==> We certainly have to work closely together on that (maybe more little
check-ins rather then huge chunks). I think the answer also depends on the
fact if we move up to WTP2 with M3 or not (haven't gotten any response on
the list w.r.t to Michaels email). If we do, I would expect merge problems
taking the current codebase as a base for our work.
OK, I see.
It seems to me that we'll need a branch for our work, am I correct?
Thanks a lot for contacting WSDL guys. Here are my comments:
b.) If it is, then the reason why you have duplicate code in there is the
fact that once the DOM is build by the SSE-part of the Editor, but when
the
editor is not available it is build by WSDLResourceImpl.getDocument() ?
b) The two scenarios are different. For example, the code in the editor
is
being passed a DOM, the same DOM used by the source editor. On the other
hand, our RAD validator for example uses the code in WSDLResourceImpl. The
SSE DOM is a more flexible DOM in that it tolerates malformed XML and
infers as much as possible from the content. This is very useful in the
editing scenario. The DOM used by the WSDL resource on the other hand is
your standard JAXP DOM that cannot tolerate malformed XML.
My gut says that using two different DOMs is not that great. And I think
that such code shouldn't be too easy to maintain, especially for newcomers.
(I was really confused by saying "this code [in WSDLResourceImpl] looks
just
redundant.", you noted it right :) )
But the completely grey area for me is: can we use only SSE DOM? Can we use
BPEL validator to help us identify problems like malformed XML?
Thanks,
Vitaly.
PS Can we move our discussion to the bpel-dev@ list? This will both allow
other parties make their comments and let other world know that the project
is alive and well :)
-----Original Message-----
From: Simon D Moser [mailto:SMOSER@xxxxxxxxxx]
Sent: Tuesday, May 29, 2007 8:37 PM
To: Tishkov, Vitaly V
Cc: Michael Illiger2
Subject: RE: Our Dom Facading Knowlegde
Hi Vitaly,
although I haven't fount the time today to look closer into this, I am not
ruling out that the information I sent wasn't entirely correct.
Now basically I agree with most what you said - except one thing: I guess
that the model itself needs a way to load a BPEL (DOM) without the editor,
and it must still work., This might be the reason for the confusion I had,
and also you had when you say "this code [in WSDLResourceImpl] looks just
redundant."
Imagine a step at e.g. deployment of the process, where no editor is
available. In this case, I guess whatever happens in buildAndSetModel();
must also happen in getDocument() etc. Now instead of having two pieces of
code with the same functionality, I'd rather unify them if this is
possible
(and put them somewhere in the model).
Now: having said that, that does *not* mean that we cannot start the way
you proposed, e.g. using the structuedSourceEditor as a "kick-off" point
for that work. It's just that eventually we need both ways, since
otherwise
Bruno who does the runtime adapters is probably lost.
Now let me try to answer the other questions:
@step1 you wrote: If I'm correct with the way WSDL editor build models
(see
above), then we'll have to use Editor (actually, StructuredTextEditor) to
build DOM tree. If you apply my patch I sent to the list a few days ago
(see message "adding source view - patch #1"), then you have the DOM tree
built. We'll need to refactor code which builds BPEL tree from the DOM
tree. As far as I understand, BPELReader can be eliminated this way.
==> Agreed. As I said before, I think we can start from there.
@1. Do we need to separate "core" and "view" functionality in BPELEditor
sometimes in between these steps?
==> Not sure what you exactly mean by that. What exactly is "core", what
is
"view" ? Assuming that "core" is loading etc, there might be a need to
seperate some of this (which might go in line with the refactoring that we
have to do in order to add the source view properly, correct ?. Either
way,
I think I need to understand your question better.
@2. Is it possible to do our task with the "separating" task in parallel?
Do you expect merge problems later?
==> We certainly have to work closely together on that (maybe more little
check-ins rather then huge chunks). I think the answer also depends on the
fact if we move up to WTP2 with M3 or not (haven't gotten any response on
the list w.r.t to Michaels email). If we do, I would expect merge problems
taking the current codebase as a base for our work.
@3. Can you please contact WSDL guys and ask them if I was right with the
evaluation of how they build models (as it's different from what they said
you before)?
==> I will forward your email to them to find out.
Cheers
Simon
Simon Moser, M.Eng.
Websphere Integration Mail: IBM Deutschland Entwicklung
Developer Development smoser@xxxxxx. GmbH
Team Lead BPEL Editor com Vorsitzender des
Dept. 4722, Bldg. Phone: Aufsichtsrats: Martin Jetter
71032-01, Room 086 +49-7031-16-43 Geschäftsführung: Herbert
Websphere Solutions and 04 Kircher
Services Fax: Sitz der Gesellschaft:
IBM Deutschland +49-7031-16-48 Böblingen
Entwicklung GmbH 90 Registergericht: Amtsgericht
Schönaicherstr. 220, D - Stuttgart, HRB 243294
71032 Boeblingen
"Tishkov, Vitaly
V"
<vitaly.v.tishkov To
@intel.com> Simon D Moser/Germany/IBM@IBMDE
cc
05/28/2007 06:18 Michael Illiger2/Germany/IBM@IBMDE
PM Subject
RE: Our Dom Facading Knowlegde
Hi Simon,
I did some investigations about how WSDL Editor builds models (both DOM
and
WSDL).
Surprisingly, it's different from that you notes in 2.) of your message.
I used the latest sources from Eclipse CVS.
2.) Starting point for reading in an XML stream is the
WSDLResource.getDocument() method. It parses the Document and the
interesting code is in "handleDefinitionElement()
Did you mean WSDLResourceImpl.getDocument()?
I set breakpoints in all
getDocument(InputSource inputSource, ErrorHandler errorHandler)
and
getDocumentUsingSAX(InputSource inputSource)
and
handleDefinitionElement(Element element)
and the debugger didn't stop there!
At first glance this code looks just redundant.
--------------
The way they build model IMHO looks this way.
The most interesting method is ASDMultiPageEditor.createPages(). See my
comments in the method body.
protected void createPages()
{
selectionProvider = getSelectionManager();
getEditorSite().setSelectionProvider(selectionProvider);
createGraphPage(); -> just a control for the graph page is created
here
createSourcePage(); -> a control for the source page and it's contents
is created here + the DOM model is built; the
actual DOM model is built in AbstractModelLoader.
createModel(IStructuredDocument structuredDocument, String baseLocation,
IModelHandler handler) - see the Stack Trace 1 at the bottom of the
message
buildAndSetModel(); -> the WSDL model is built from the DOM model
here;
most of work is done in
org.eclipse.wst.wsdl.ui.internal.text.WSDLModelAdapter.createDefinition
(final Document document) - see the Stack Trace 2
DOM and WSDL models are connected to be in
sync in this method too:
modelReconcileAdapter = new
WSDLModelReconcileAdapter(document,
definition);
initializeGraphicalViewer(); -> the graphical viewer contents based on
the WSDL model is initialized here
setActivePage(getDefaultPageTypeIndex());
getSelectionManager().setSelection(new
StructuredSelection(getModel()));
PlatformUI.getWorkbench().getHelpSystem().setHelp(graphicalViewer
.getControl(), ASDEditorCSHelpIds.WSDL_DESIGN_VIEW);
}
I am thinking we can maybe take a multi-step approach:
Step 0.) Try to map the WSDL approach to BPEL, e.g. "Definition" becomes
"Process", WSDLResource becomes BPELResource etc.
Yes, I can't disagree with it.
Step 1.) Modify the model as such that the "Reader" will vanish (No use
of
the Editor, no sync yet, just holding on to the DOM Tree)
If I'm correct with the way WSDL editor build models (see above), then
we'll have to use Editor (actually, StructuredTextEditor) to build DOM
tree.
If you apply my patch I sent to the list a few days ago (see message
"adding source view - patch #1"), then you have the DOM tree built. We'll
need to refactor code which builds BPEL tree from the DOM tree. As far as
I
understand, BPELReader can be eliminated this way.
Step 2.) Modify the model as such that the "Writer" will vanishe (No use
of
the Editor, no sync yet, just preserving the DOM Tree)
Yes.
Step 3.) Start working on "sync" in one direction, e.g. modifying the EMF
onto the DOM (this will probably need the Editor)
Yes.
Step 4.) Start working on "sync" in the other direction, e.g. Modifying
the
DOM will be reflected in the EMF (This even needs the Editor with a
source
view).
Yes.
A few questions:
1. Do we need to separate "core" and "view" functionality in BPELEditor
sometimes in between these steps?
2. Is it possible to do our task with the "separating" task in parallel?
Do
you expect merge problems later?
3. Can you please contact WSDL guys and ask them if I was right with the
evaluation of how they build models (as it's different from what they said
you before)?
Thanks,
Vitaly.
PS
--------------
Stack trace 1.
--------------
XMLModelLoader(AbstractModelLoader).createModel(IStructuredDocument,
String, IModelHandler) line: 113
FileBufferModelManager.getModel(IStructuredDocument) line: 615
ModelManagerImpl._getModelFor(IStructuredDocument,
ModelManagerImpl$ReadEditType) line: 393
ModelManagerImpl.getModelForEdit(IStructuredDocument) line: 1020
StructuredTextEditor.doSetInput(IEditorInput) line: 2113
AbstractTextEditor$19.run(IProgressMonitor) line: 2680
ModalContext.runInCurrentThread(IRunnableWithProgress, IProgressMonitor)
line: 369
ModalContext.run(IRunnableWithProgress, boolean, IProgressMonitor,
Display)
line: 313
ApplicationWindow$1.run() line: 784
BusyIndicator.showWhile(Display, Runnable) line: 67
WorkbenchWindow(ApplicationWindow).run(boolean, boolean,
IRunnableWithProgress) line: 781
WorkbenchWindow.run(boolean, boolean, IRunnableWithProgress) line: 2362
StructuredTextEditor(AbstractTextEditor).internalInit(IWorkbenchWindow,
IEditorSite, IEditorInput) line: 2698
StructuredTextEditor(AbstractTextEditor).init(IEditorSite, IEditorInput)
line: 2725
StructuredTextEditor.init(IEditorSite, IEditorInput) line: 2615
InternalWSDLMultiPageEditor(MultiPageEditorPart).addPage(int, IEditorPart,
IEditorInput) line: 181
InternalWSDLMultiPageEditor(MultiPageEditorPart).addPage(IEditorPart,
IEditorInput) line: 155
InternalWSDLMultiPageEditor(CommonMultiPageEditor).createSourcePage()
line:
495
InternalWSDLMultiPageEditor(ASDMultiPageEditor).createPages() line: 145
InternalWSDLMultiPageEditor.createPages() line: 403
InternalWSDLMultiPageEditor(MultiPageEditorPart).createPartControl(Composite)
line: 278
EditorReference.createPartHelper() line: 662
EditorReference.createPart() line: 421
EditorReference(WorkbenchPartReference).getPart(boolean) line: 586
EditorPane(PartPane).setVisible(boolean) line: 299
-- cut -
--------------
Stack trace 2.
--------------
WSDLModelAdapter.createDefinition(Document) line: 78
InternalWSDLMultiPageEditor.buildModel(IFileEditorInput) line: 136
InternalWSDLMultiPageEditor(ASDMultiPageEditor).buildAndSetModel() line:
171
InternalWSDLMultiPageEditor(ASDMultiPageEditor).createPages() line: 147
InternalWSDLMultiPageEditor.createPages() line: 403
InternalWSDLMultiPageEditor(MultiPageEditorPart).createPartControl(Composite)
line: 278
-- cut --
-----Original Message-----
From: Simon D Moser [mailto:SMOSER@xxxxxxxxxx]
Sent: Thursday, May 24, 2007 9:17 PM
To: Tishkov, Vitaly V
Cc: Michael Illiger2
Subject: Our Dom Facading Knowlegde
Hi Vitaly,
as promised here the wrap-up of what I have in mind for the DOM Facading
work. I think I made the problem clear (the fact that we discard the DOM
nodes rather then maintaining them), and that we should strive for a
resolution similar to the one that is in WSDL.
Here are my Notes from the call I had with the WSDL guys, and that I
tried
to get across today on the phone:
1.) All classes' BaseClass is a thing called "WSDLElement". It has a
field
"element" that has a reference to the actual DOMElement . The root node
is
modeled in the Definition (root element of a WSDL).
==> Since we use WSDLs ExtensibilityElement as our base class, we get
this
for free.
2.) Starting point for reading in an XML stream is the
WSDLResource.getDocument() method. It parses the Document and the
interesting code is in "handleDefinitionElement()
==> We need to do something similiar on our ProcessResource I guess.
Maybe
it is also a good idea to write a little Eclipse Action to do the reading
in (instead of using the Editor in the first shot, since this probably
causes more confusion)- u know, just a helper Eclipse Action that reads a
BPEL in and then writes is back out (no use of the Editor in the first
iteration - see list of steps below).
3.) In the Class DefinitionImpl, the method setElement() is interesting.
It
basically has a eventListener functionality, that then does
elementContentChanged() and reconcileContent() . This boils down to
WSDLElementImpl.setElement() which boild down to setElementGen(). THis
class has an override of eNotify(), which adapts the contents for
synchronisation between the DOM and the EMF.
4.) The "real" work is done in all the "leaf" classes of the model. They
all have methods reconcileAttributes(), changeAttributes(),
reconcileElements etc. Those are basically the methods that we have in
the
BPELReader and BPELWriter today, where reconcileXXX would be similar to
XMLtoXX in the Reader, and changeXXX wold be similar to XXXtoXML in the
Writer.
I am thinking we can maybe take a multi-step approach:
Step 0.) Try to map the WSDL approach to BPEL, e.g. "Definition" becomes
"Process", WSDLResource becomes BPELResource etc.
Step 1.) Modify the model as such that the "Reader" will vanish (No use
of
the Editor, no sync yet, just holding on to the DOM Tree)
Step 2.) Modify the model as such that the "Writer" will vanishe (No use
of
the Editor, no sync yet, just preserving the DOM Tree)
Step 3.) Start working on "sync" in one direction, e.g. modifying the EMF
onto the DOM (this will probably need the Editor)
Step 4.) Start working on "sync" in the other direction, e.g. Modifying
the
DOM will be reflected in the EMF (This even needs the Editor with a
source
view).
Opinions ?
Cheers
Simon
Simon Moser, M.Eng.
Websphere Integration Mail: IBM Deutschland Entwicklung
Developer Development smoser@xxxxxx. GmbH
Team Lead BPEL Editor com Vorsitzender des
Dept. 4722, Bldg. Phone: Aufsichtsrats: Martin Jetter
71032-01, Room 086 +49-7031-16-43 Geschäftsführung: Herbert
Websphere Solutions and 04 Kircher
Services Fax: Sitz der Gesellschaft:
IBM Deutschland +49-7031-16-48 Böblingen
Entwicklung GmbH 90 Registergericht: Amtsgericht
Schönaicherstr. 220, D - Stuttgart, HRB 243294
71032 Boeblingen
(See attached file: ASDMultiPageEditor.java)(See attached file:
WSDLModelAdapter.java)
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|
