Home » Eclipse Projects » e(fx)clipse » Call order for declaring application model's context variables as modifiable(Is the call order, where application model's context variables are declared as modifiable, worth being reconsidered?)
| Call order for declaring application model's context variables as modifiable [message #1727631] |
Thu, 24 March 2016 14:39  |
 Niels Wuerzbach
Messages: 2
Registered: March 2016 |
Junior Member |
|
|
Application model variables not declared as modifiable already dealt with the issue, that context variables, defined in the ApplicationModel on the level of the ApplicationContext, have never been declared as modifiable - neither by the platform nor by the e(fx)clipse runtime - when starting up an actual application.
As of e(fx)clipse 2.2.0, this issue has been fixed. Thanks for that!
Unfortunately, we'd like to publish values to such context variables at an even earlier stage within the start-up process. That is, we'd like to do so within our LifeCycleManager's @PostContextCreate annotated method.
Because of the method call-order as defined in org.eclipse.fx.ui.workbench.base.AbstractE4Application.createE4Workbench(IApplicationContext, IEclipseContext), this is not working.
Here, the PostContextCreate-method is invoked in line 229, whereas the call to Util.setup(MContext, IEclipseContext), which is where the actual bugfix comes into play, and the model's context variables are going to be declared as modifiable, happens afterwards. In turn, when the LifeCycleManger's PostContextCreate-method is invoked, the context variables are not declared as modifiable and do not allow for full access.
I'm wondering if there is a specific reason for the Util.setup() call at this very position in the AbstractE4Application.createE4Workbench() method?
Wouldn't it be more appropriate to have these things being set up properly even before the PostContextCreate invocation? That way, one could access the context values as desired in the PostContextCreate-method.
This may not be considered as a 'real' problem, as for a specific application one can also adjust one's own call order accordingly. However, we're using the PostContextCreate-method to initialize the application from this exact position, most early in the overall start-up process, and in a centralized manner.
Littering the initialization process over PostContextCreate-, and e.g. ProcessAdditions-method, is not the best option for several reasons. The same applies to delaying the initialization as a whole, for instance by moving all our code to
the ProcessAdditions-method.
So what do you think. Are my considerations worth to adjust the createE4Workbench() accordingly?
Thanks in advance for hopefully nice new thoughts, or reasons regarding this matter.
Regards
-Niels
|
|
|
| Re: Call order for declaring application model's context variables as modifiable [message #1727661 is a reply to message #1727631] |
Thu, 24 March 2016 20:50  |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi,
I don't think what you request is possible.
To have an MContext instance we need to have the MApplication-Model and
@PostContextCreate is to be called as soon as simply the IEclipseContext
has been bootstrapped (it would even probably break code because someone
might rely on the fact that before the model is loaded
@PostContextCreate is called eg because they have to custom resource
loading going on)
I'm not sure why you need modifiable variables from the model at this
point because there's no real IEclipseContext hiearchy at that point so
you could:
a) call IEclipseContext#set directly
b) you could use IEclipseContext#declareModifiable (in case somecode
down in your @PostContextCreate uses modify)
Tom
On 24.03.16 20:52, Niels Wuerzbach wrote:
> Application model variables not declared as modifiable already dealt
> with the issue, that context variables, defined in the ApplicationModel
> on the level of the ApplicationContext, have never been declared as
> modifiable - neither by the platform nor by the e(fx)clipse runtime -
> when starting up an actual application. As of e(fx)clipse 2.2.0, this
> issue has been fixed. Thanks for that!
>
> Unfortunately, we'd like to publish values to such context variables at
> an even earlier stage within the start-up process. That is, we'd like to
> do so within our LifeCycleManager's @PostContextCreate annotated method.
>
> Because of the method call-order as defined in
> org.eclipse.fx.ui.workbench.base.AbstractE4Application.createE4Workbench(IApplicationContext,
> IEclipseContext), this is not working.
> Here, the PostContextCreate-method is invoked in line 229, whereas the
> call to Util.setup(MContext, IEclipseContext), which is where the actual
> bugfix comes into play, and the model's context variables are going to
> be declared as modifiable, happens afterwards. In turn, when the
> LifeCycleManger's PostContextCreate-method is invoked, the context
> variables are not declared as modifiable and do not allow for full access.
>
> I'm wondering if there is a specific reason for the Util.setup() call at
> this very position in the AbstractE4Application.createE4Workbench() method?
> Wouldn't it be more appropriate to have these things being set up
> properly even before the PostContextCreate invocation? That way, one
> could access the context values as desired in the PostContextCreate-method.
>
> This may not be considered as a 'real' problem, as for a specific
> application one can also adjust one's own call order accordingly.
> However, we're using the PostContextCreate-method to initialize the
> application from this exact position, most early in the overall start-up
> process, and in a centralized manner.
>
> Littering the initialization process over PostContextCreate-, and e.g.
> ProcessAdditions-method, is not the best option for several reasons. The
> same applies to delaying the initialization as a whole, for instance by
> moving all our code to the ProcessAdditions-method.
>
> So what do you think. Are my considerations worth to adjust the
> createE4Workbench() accordingly?
>
> Thanks in advance for hopefully nice new thoughts, or reasons regarding
> this matter.
>
> Regards
> -Niels
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 00:02:38 GMT 2024
Powered by FUDForum. Page generated in 0.03693 seconds |
] 
Search
Help
Register
Login
Home
