[...] > OK, that kills the extend idea, but doesn't change my initial > statement. I'm against adding a second layer of complexity to the > annotation processing we have when it doesn't seem any better to me.
where is the 2nd layer? It's a another possibility. Ok there are 3 more methods in IInjector but that's it (see https://github.com/tomsontom/eclipse.platform.runtime/commit/80827b011f9916884b65c8202f0a91ecdc3ed1aa). I'm not yet argueing that this is the way to go for the base e4 framework because we should stick with one or the other and we already have those @Execute, @ProcessAddition but providing such an API on the DI side for other. That's why I implemented the lifecycle stuff for now with annotations. An advantage to the @Invoke is that the they'd work similar to @EventTopic given we have the event: "MenuRendered" the event code would look like this: @Inject public void rendered(@UIEventTopic("MenuRendered") Menu menu) { } and the tightly scoped lifecycle: @Invoke("MenuRendered") public void rendered(Menu menu) { } Like stated above I think the way for the framework to go is with specific annotation and because we can't use inheritance we'll probably have to group the annotations inside a package and/or to avoid confusion prefix them with @MenuAboutToHide, @WindowAboutToHide, ...? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl geschäftsführer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
