Tishkov, Vitaly V wrote:
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 ?
[Vitaly]
I wanted to note
that in XML/XSD/WSDL editors the “core” part doesn’t _display_ the model.
OK
And how does that tie into the EMF-> DOM and DOM->EMF problem re
facading that Simon elaborated before...
[Vitaly]
I didn’t
think about it before. It’s a good point.
This EMF <-> DOM binding is going to be really a piece of work at
the end.
If the text editors are using XML DOM, then we must make the both such
layers (the DOM facade) and the EMF object model equivalent from the
perspective of mutable models that we would support.
This is clearly a little more then just a facade of the DOM in
direction and so I would tend to agree with Simon that this is a
"bigger" problem.
However, this has already been done by the WSDL and XSD editors, so I
am a little puzzled as to why we can't use that approach to facading.
They are both using the GEF editors for the graphical part, and while
they are as not heavy handed as the BPEL graphical editor, the rules
are the same here, aren't they ?
Nonetheless, if this was solved right, I think the editor could be way
cooler. One of the features (albeit small ones) that we have had on our
Collaxa editor was the ability to "copy" out BPEL source (so you would
copy an element, let's say a sequence and the clipboard would contain
the serialized version of it in XML) and to "paste-in" the source - so
for example, you could clip-and-drag or copy-and-paste any BPEL source
into the editor (XML source). The resulting operation would parse the
content and create the visual representation for the fragment in the
insertion point. It was a silly little thing, but it made a good demo
:-)
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?
[Vitaly]
I think that from
the code design point of view it’s better to separate “core” and
“view” functionalities. I assume that tabs (design and source) should
have equal “power”.
Agreed. At the end it is a big refactoring issue ...
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.
[Vitaly]
OK, I’ll
try to separate BPEL “core” functionality from “view”
functionality again.
But I’ll need some help from the community: every time I do a big
enough step
in that direction I’m going to send for a review a patch to the list
with
explanations what is done; any comments/suggestions/criticism is very
welcome.
Is
this OK?
Absolutely. I suppose if this is enough of a job we could even create a
branch at some point for these changes so that we don't wreck what's on
the tip right now.
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|
