Re: [e4-dev] Annotations vs Events and when should we extend them ?

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

[...]

> 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