As for code completion I think we can group them as constants of a central place like
@Blabla(ILifecycleEvents.Menu.AboutToShow) or @Blabla(ILifecycleEvents.Window.AboutToClose) rather than plain strings or key=value pairs. I also see as an advantage that the framework behavior will change depending on what the annotated method will return (close the window or not, show the part or not etc.). I'm not sure how or if we can do this using only event dispatching. Sopot On Thu, Nov 8, 2012 at 1:50 PM, Wim Jongman <[email protected]> wrote: > 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]>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 >> http://www.BestSolution.at phone ++43 512 935834 >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
