[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [bpel-dev] DOM Facading / source Editor
|
Hi all,
no avail today for me. Next Wednesday (23) would be good, but apparently
Michal cant participate that time. Guess we must postpone to the week
starting may 28
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
Bruno Wassermann
<B.Wassermann@cs.
ucl.ac.uk> To
Sent by: "'BPEL Designer project developer
bpel-dev-bounces@ discussions.'"
eclipse.org <bpel-dev@xxxxxxxxxxx>
cc
05/17/2007 10:43 Subject
PM RE: [bpel-dev] DOM Facading /
source Editor
Please respond to
"B.Wassermann"
<B.Wassermann@cs.
ucl.ac.uk>;
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
I probably wont be able to join at any of these times I am afraid (and the
week after am in Minneapolis and won’t be online much or available for
calls, I am afraid). But I’ll try tomorrow and if can’t make it I am sure
someone will let me know what I missed.
-- Bruno
From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On
Behalf Of Michal Chmielewski
Sent: 17 May 2007 16:31
To: BPEL Designer project developer discussions.
Subject: 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."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
