Here's a redux from my perspective: Annotated Methods:
Using 'invoke' and annotations is *required* if there's an expected return value (a la @CanExecute...). It also requires some place to store the instance of the Object to call the invoke on. Note that if there is more than one instance being 'invoked' then it starts getting complicated because you end up with more than one 'answer' and have to arbitrate between them if they differ. UILifeCycle Events: Using events is best when there is no requirement for information to be returned and there are an unknown number of potential clients of the 'event'. In the original case in the defect the second use seems best because it's *very* likely that more than one client may want to know when the application is 'up'. The Mix: The 'Login' use case is interesting because it would have to be done through some annotated method (most likely in the defined LifeCycle class). Note however that each e4 app may have different requirements as to what *it* needs; some may need log in, others may need to define a link to a service (like the IDE connecting to the workspace) and others may need both or something even more complex. So what's the responsibility of the E4Application here ? It's apparent that we need at least one 'checkpoint' defined in out startup lifecycle and handled in the defined life cycle class. Now it gets fuzzy...;-), do we need more than one check point ? I'd propose 'no' but that we guarantee that past this point that IWorkbench#close() will cleanly close the app. Aside from the new check point method annotation expected to be (optionally) defined in the life cycle class we should leave it up to the application developer what other annotations / class instances they want and how they're created / (re)stored, when they are invoked... As far as 'MenuAboutToShow' and the other related ones it appears that they should be defined through the UIEvents specifications as we currently do for the UILifeCycle.ACTIVATE event. Eric From: Tom Schindl <[email protected]> To: [email protected] Date: 11/08/2012 09:45 AM Subject: Re: [e4-dev] Annotations vs Events and when should we extend them ? Sent by: [email protected] [...] > 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. > No we can't veto stuff with event dispatching, i mentionned that in my first answer, if you need to return value you have to use annotations. We are not using it in our current lifecycle stuff but we should e.g. to cancel the start e.g. because the login failed, ... . 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
