[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[bpel-dev] RE: Our Dom Facading Knowlegde
|
Hi Vitaly,
first I moved the discussion to the list - not even sure why this was
started in private ;-)
>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.
I am OK with the approach. However, the thing is that we probably must use
StructuredSourceEditor or StructuredXMLEditor or something.
> Yes, your assumption is correct. Sorry for being not clear.
> I'll send my proposal for separating "core" and "view" in another message
Ok, cool. I'm waiting for that one then.
>OK, I see.
>It seems to me that we'll need a branch for our work, am I correct?
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?
>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?
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)
