So how do you then envision to have the IInjector API for that? As nice that would be it can't be implemented! Hence I switched from my @Lifecycle to @Invoke!
So from an API designer point of view a big YES, from the implementors point of view a strict NO (can't be implemented) Tom Am 08.11.12 13:50, schrieb Wim Jongman: > Why not one annotation like @Menu for menu specific stuff > > like > > @Menu(aboutTohide=true) (or smth else that can be used with code completion) > > or something similar that copies the wanted menu API. I don't think that > each "method" should have its own annotation. > > I would also prefer a specific @LIfecycle(xxx) annotation over > @Invoke(xxx) so that it makes sense to developers. > > Regards, > > Wim > > > > > > On Thu, Nov 8, 2012 at 1:28 PM, Tom Schindl <[email protected] > <mailto:[email protected]>> wrote: > > [...] > > > 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 <tel:%2B%2B43%20512%20935833> > http://www.BestSolution.at phone ++43 512 > 935834 <tel:%2B%2B43%20512%20935834> > _______________________________________________ > e4-dev mailing list > [email protected] <mailto:[email protected]> > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > -- 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
