Wim, great blog !! Do you submit these things to PlanetEclipse ? The reason I didn't re-use the existing 'views' extension is simply that its schema enforces a restriction that the 'class' implement ViewPart (IViewPart?). If you were to use the existing 'view' extension then you would get incorrect information on both the 'class' definition link (the initial values in the dialog would have you subclassing ViewPart) and the 'Browse' (which only looks for IViewParts). I don't know of any way to 'mix' both behaviors in the same Extension...
I'll see if I can cover both yourand Jonas' other questions at the same
time since they're somewhat related:
The ultimate goal is to allow us to consume and render any valid UI model
containing a mix of legacy and e4 components. There are a few steps
required in order to accomplish this:
1) Fix our current code so that we DO NOT mess with the model either at
startup or shutdown. This means removing any code on the IDE side that
seeks to manipulate the model (We will have to manage new / stale
contributions somehow but this is part of Jonas' question so we'll get to
it later). This should allow the RCP client to construct a mixed model of
their own specification, knowing we aren't going to do dumb things like
adding a Search bar or Perspective Switcher.
My current 'plan' is to see if we can produce a two-stage approach to
defining the model in the IDE. First we'd take the existing LegacyIDE.xmi
file combined with any extensions (either through Extension Points or
fragments / processors) and produce the starting IDE *for a particular
install*. From that point this would become the starting model for all new
workspaces. From that point on we should simply store / load the model
without change.
2) We need to change our rendering setup to allow us to arbitrarily 'grow'
any necessary 3.x artifacts as needed (including those for any direct e4
parts). This will mean moving code out of our CompatibilityPart[View |
Editor] and into some part of the rendering stage. This will require that
we introduce some new life cycle events...see below.
NOTE: Editors are going to be significantly more work since we first have
to work out what the model's "EditorDescriptor" looks like and how it works
(including suffix bindings, content types...). Perhaps we should just
scrape the current org.eclipse.ui.editors extension point for what it has ?
Now on to Jonas' question regarding fragment processing...I haven't paid
much attention to this as it wasn't required for the IDE. My impression
from the EclipseCon BOF was that it's quite a mess presently. Not only are
there the issues you're seeing but we have no way currently to apply model
processors to newly created elements (i.e. a newly opening window). From my
POV model processing == registry processing; in fact our some of our
current registry processing is already handled through model processors but
not all (i.e. ViewRegistry processing).
There are a number of things we might do here:
1) Add new life cycle events; some matching the current IPartListener
events add at least two others "AboutToRender" and "FinishedRendering".
This will allow us to extend the model processing to listen on the new
events and take appropriate action (likely needs a change to the fragments
EP along the lines of an 'ApplyWhen' field...).
2) Fix the model to at least allow Commands / Handlers to be late bound
(i.e. relax the MHandler's model to allow 'null' for the Command ref) and
set the reference when needed (store the command ID in the persistentData
map ?).
3) Freaking define the start up life cycle as a state machine, with
diagrams ! In my experience the exercise of defining the diagram provides
focus for the code; what has to be done and where it should go should all
be in reference to the diagram (possibly leading to changes in the diagram
should breaking use cases be discovered). Transitions through this state
machine should all be published on the event bus...
BTW, two questions about the current fragment processing:
1) Why don't we handle processing a model fragment by running it through a
regular ModelProcessor (called FragmentProcessor) ? It seems somewhat
strange that we can't build the fragment processing on top of the more
general model processor.
2) I see that there's a sorting stage in place to address the fragment
ordering issues. My expectation based on our uniform lack of success in
doing this for the 3.x extensions is that we might be better off going with
the pattern we use to process 'org.eclipse.ui.menus' extensions. These
extensions match the 'add this at location <x>' approach we use for
fragments but rather than sorting them we simply use the following:
- Attempt to locate the insertion point.
- Found it....success, process the fragment
- Not found...fail, add it back at the end of the list to be
processed later
We're only finished when the list is empty or when a full pass over it has
*no* successes (meaning that everything remaining cannot be sited).
This works extremely well in that it completely ignores the order in which
the extensions arrive from the registry and handles even deeply nested
locations. Note that in this case we never have to look at the *contents*
of a fragment since once it's applied any children added will be available
as site locations for subsequent extensions...should we give this a try
while we're refactoring the processing ?
Dang ! This is a bit longer than I expected. I'd love to start up the
conversation about the start up life cycle, who wants to toss out the first
cut..;-).
Onwards,
Eric
From: Wim Jongman <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 08/06/2013 05:08 AM
Subject: Re: [e4-dev] Focus for Luna
Sent by: [email protected]
Hi,
Great changes guys! "e4view". In case you missed it, I have blogged about
this change [1]. Eric, can you share some of the implementation details
with us? Do you create an invisible counterpart e3 view as a bridge?
What are the plans for the next step?
Cheers,
Wim
[1]
http://industrial-tsi-wim.blogspot.nl/2013/08/a-giant-leap-for-eclipse-rcp.html
On Sun, Aug 4, 2013 at 4:41 PM, Jonas Helming <[email protected]
> wrote:
Hi,
are there any plans to support the following use case:
I have an existing 3.x application running on compat layer. Now I want to
add a new view using fragments, meaning I plug a new e4 view into the
model which was created by the compat layer?
Currently this is not possible, because the model is not fully created
when fragments or processors are merged.
Regards
Jonas
Am 02.08.2013 16:19, schrieb Eric Moffatt:
Wim, we've already started on at least part of if. I've just
committed changes to the org.eclipse.ui.views extension point that
allows someone using Eclipse 4 to declare a new view with its
implementation being e4 style (DI...). This is the first test case;
if it seems to be the correct direction we expect to do this for
other extensions such as org.eclipse.ui.menus (e4 Handlers...).
We also have ongoing work in progress that will alter how we
integrate with the legacy 3.x API so that creation of any necessary
3.x artifacts (Workbench[Window, Page], IWorkbenchParts,
ViewReferences, PartSites...) all get created 'automagically'
during the rendering stage. Part of this will be to add the new
life cycle events to allow this to happen. Once done your mixed
model RCP app should be capable of consuming most (if not all)
existing views / editors, even those that need access to
EditorReferences...
In fact we've just been discussing how we might override the
default renderer factory so that we can supply ones specific to the
IDE (so that they can create the necessary 3.x artifacts without
introducing dependencies.
Onwards,
Eric
Inactive hide details for Wim Jongman ---08/02/2013
08:28:12 AM---Hi, When we spoke on the e4/RCP BoF it was made
clear that alWim Jongman ---08/02/2013 08:28:12 AM---Hi, When we
spoke on the e4/RCP BoF it was made clear that allowing the e4
From: Wim Jongman <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 08/02/2013 08:28 AM
Subject: [e4-dev] Focus for Luna
Sent by: [email protected]
Hi,
When we spoke on the e4/RCP BoF it was made clear that allowing the
e4 programming model on e3 was the first priority for Luna (or
maybe that was what I wanted to hear?).
On the plan [1] the first item on the list is the effort to use e4
in the e3 context. However, when I go to the milestone breakdown
[2] all of these items are still on the unscheduled list.
Is there already an idea what the current focus is for Luna?
Thanks and best regards,
Wim
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
