Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] DOM Facading / source Editor
Tishkov, Vitaly V wrote: 
Simon, all,

  
Therefore, it is important to find out what Vitaly is planning for the
sourceView ? Is it something like the SSE Editors (Structured Source
Editors) that are available for e.g. XML ?
    
Yes, this is true. 
There are two reasons for that:
	1) BPEL editor will be consistent with other XML and XML-like Eclipse editors (WSDL, XSD);
	2) code from XML/XSD/WSDL editors can be reused.


There is a problem though. 
WSDL/XSD/XML editor use org.eclipse.ui.MultipageEditorPart which is designed for creating multi-page editors. 

As far as I understand WSDL/XSD/XML editor cores are build on top of this class, i.e. they build a model from a document, create additional views like outline view, handle property changes, etc. Graphic and source parts of the editors are just views which display the model various ways. 

In our case BPELEditor is that core part but it also displays a document model.
Not sure I see the distinction between the two you just mentioned ... that is:
Graphic and source parts of the editors are just views which display the model various ways. 

In our case BPELEditor is that core part but it also displays a document model.
Any view can alter the model, for example, the outline view does this in our editor as well. Can you elaborate ?

And how does that tie into the EMF-> DOM  and DOM->EMF problem re facading that Simon elaborated before...

My initial idea was to create a subclass of org.eclipse.ui.MultipageEditorPart, move there all the editor core functions from BPELEditor and make BPELEditor just a view. This will allow adding source tab view (or any other views, e.g. XML view) easily. But BPEL editor traces are everywhere and it's a big challenge to do move core editor code from BPELEditor to anywhere else. I spent a few days on that and gave up eventually.
I guess my question is: if BPELEditor has this "core" functionality besides just being a view, that's really normal, isn't it? 

You are right that BPEL editor refs are pretty much everywhere, but I think that they are broken down into 2 areas:
1) those that deal with graphical editing (so these would not need to be changed)
2) those that deal with other things (these may have to be moved to the multi page editor).

Question is of course how much of (1) and (2) there is.
So, I decided to do the following: utilize a subclass of org.eclipse.ui.MultipageEditorPart, add BPELEditor and org.eclipse.wst.sse.ui.StructuredTextEditor as views but keep core editor functionality in BPELEditor. This seems to be a bit lame from the design point of view but if anyone can propose anything else or volunteer to move core editor functionality from BPELEditor to a subclass of org.eclipse.ui.MultipageEditorPart, it would be great. I can clean up code I have at the moment and send it to the volunteer.
We were not thinking of doing the source view quite until after 1.0 initially and your entry into this puzzle has certainly put that up for discussion.

I think you are the volunteer in this case on this one, for the moment :-)

Perhaps some one else can offer some help regarding at least dividing up the problem and at least identifying the areas of concern.

  
I think we need to have a phone call on this soon, since we have to decide
how to proceed from here. I understood the concepts that I have to watch,
but this change requires a bigger amount of restructuring and even more
testing, so were looking at something like 10-15 days full time work (which
really is hard to contain until end of May).
    
I'll need to stay quite late in the evening (I'm located in St. Petersburg, Russia, GMT+3). I can do it this Friday (May, 18), next Monday (21) and next Wednesday (23).
Let's shoot for the call this Fri as follows ... alternatives with respect to times would be:

Thur 11pm PST -> 7am London, 8am Germany, 10 am St.Petersburg on Fri
Fri     7am  PST (3pm London, 4pm Germany, 6pm St. Petersburg) but I have no more then 55 minutes at that time :-)
Fri     9am  PST (5pm London, 6pm Germany, 8pm St. Petersburg)

If I don't get reply from you before 11pm PST today, regarding preference, I'll assume it's the last one (usual).

-m



-- 
Michal Chmielewski, CMTS, Oracle Corp, 
W:650-506-5952 / M:408-209-9321 

"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."

Back to the top