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

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

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 <tom.schindl@xxxxxxxxxxxxxxx
> <mailto:tom.schindl@xxxxxxxxxxxxxxx>> 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
>     e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> 
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> 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