Community
Participate
Working Groups
At present the context for model elements is created by the PartRenderingEngine#createGUI(). That's problematic in a number of levels: - there is no place to fill in the context for a given element type (say, I'd like to make a service available on MWindow level) - the lifecycle of model element is tied to its visibility. As an extreme example, how about headless app that wants to do some query or transformation on the model? - most interestingly: The model's XML seems like a good place to put description of services avaiable, thus fixing the problem of guessing which services are available. (In a nutshell, the XML we now use for the chain: Interface -> Declarative Services -> OSGI context -> model element context would be much more straightforward if we were to put description of services in the model's XML.)
Just some thoughts on the many things we currently do that are related or that we might need to consider while looking at this. Section 1: Services 1) we create a number in the E4Application, creating a default app context 2) we use DS and OSGi to provide some services or service creation functions 3) We use ContextFunctions to create the mediator services (See section 2). These often use #1 or #2 to get into the context chain. 4) In the compatibility layer, we have hardcoded places in Workbench/WorkbenchWindow/WorkbenchPage/PartSite/PageSite that also adds to the context. 5) We have a lifecycle object or pattern that can be used to modify the system. Is it just one? 6) We have the ModelProcessors, which can be model fragments (preferred) or actual processors. They run before the deltas start up (and are a good candidate for processing Extension Points). These aren't really about services but about contributing to the stable part of the model. 7) We have the Add-Ons. I'm not sure when these get processed, but they seem to be a good candidate for setting up event handlers to respond to model change 8) IEventBroker handlers - it seems to me that these can be written to supply some specific services. ex: When an MWindow Context becomes available (a new WorkbenchWindow, for example) the appropriate service or CF can be added to that context. Section 2: mediator services. Mediator services deal with their requesting IEclipseContext. They provide one or more of the following 3: 1) scope lookup of information 2) change the behaviour of a service request 3) lifecycle management - i.e. listeners to that service are cleaned up automatically when the context (and Model object and service) are disposed. PW
(In reply to comment #1) > 5) We have a lifecycle object or pattern that can be used to modify the system. > Is it just one? Yes, I just checked, it's only one.
+1 Currently a Window is required in the application model, it think this limits the usage of Eclipse 4. I assume there would be nice use cases for headless Eclipse 4 applications.
I agree that you should not need any ui elements in the model in order to go through the startup cycle (yo may be putting up a dialog as to which UI you want to open...;-). If this not working we should have a defect for it. We've discussed various approaches, including have the 'getContext()' method create one if it's not already there but there are issues with this. For example if we ask for the context of an MPart we'd *have* to also create the contexts of every parent MContext element in order to get the chaining correct. As far as adding services into a particular context I'd just add a listener for MContext's 'context' going non-null, checking the element type to see if it's an MWindow (or whatever) and adding the services there. Note that this happens before the widget is rendered so the new services will be available.
We do this in our tests.
