[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [bpel-dev] DOM Facading / source Editor
|
MIchal,
we can do it the same way the WSDL/XSD model do it .. I even understood
what and how to do it ... it is just that this is a huger pile of work than
I intially expected ...
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
Michal
Chmielewski
<michal.chmielews To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org cc
Subject
05/18/2007 06:25 Re: [bpel-dev] DOM Facading /
PM source Editor
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
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."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
