| Re: [e4-dev] Focus for Luna |
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
Wim Jongman ---08/06/2013 05:08:07 AM---Hi, Great changes guys! "e4view". In case you missed it, I have blogged about
| Wim Jongman <wim.jongman@xxxxxxxxx> |
| E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, |
| 08/06/2013 05:08 AM |
| Re: [e4-dev] Focus for Luna |
| e4-dev-bounces@xxxxxxxxxxx |
| Wim Jongman <wim.jongman@xxxxxxxxx> |
| E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, |
| 08/02/2013 08:28 AM |
| [e4-dev] Focus for Luna |
| e4-dev-bounces@xxxxxxxxxxx |
