Okay, I just read the other mail about the menu annotations and there indeed is a @AboutToShow annotation suggested by Tom. I think it would be better to put this in an Eclipse specific annotation called @Menu with various elements that we need to get the job done. In that way, the developer can find the annotation real quick because it is so easy to remember.
@Menu for menu specific stuff @Part for part specific stuff etcetera. Regards, Wim On Thu, Nov 8, 2012 at 12:41 PM, Wim Jongman <[email protected]> wrote: > @PreDestroy is not borderline > > > On Thu, Nov 8, 2012 at 12:40 PM, Wim Jongman <[email protected]>wrote: > >> Hi, >> >> >> One rule can be that the annotation should be generic. For example, the >> @Execute, @PostConstruct, @PreDestroy (border line case) can be re-used by >> other frameworks where as @Focus replaces a IView API which is not so good >> IMHO. This opens the door to other similar annotations like @IsDirty >> @IsAboutToShow and stuff like that. >> >> > >> > I much more love us to have 1 annotation named @Lifecycle but allow it >> > to hold a meta value @Lifecycle("PROCESS_ADDITION"), >> >> The problem I see with the parameter annotations is that there is no >> documentation or code completion that tells the developer what can be used >> in certain cases. If you want to have it documented would it then not be >> better to do something like: >> >> @Lifecycle(preShutDown=true) >> >> Regards, >> >> Wim >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Nov 7, 2012 at 11:33 PM, Tom Schindl <[email protected] >> > wrote: >> >>> I started exploring this @Lifecycle stuff but made it now more generic >>> by using an injection named @Invoke >>> >>> You can find my work at >>> https://github.com/tomsontom/eclipse.platform.runtime >>> >>> Tom >>> >>> Am 07.11.12 21:44, schrieb Tom Schindl: >>> > Hi, >>> > >>> > First of all I think annotation should be used with great care here are >>> > the rules I'd set out for when to use them. >>> > >>> > * when we need to get return value e.g. to cancel something >>> > >>> > * if the information is very tightly scoped to the information provider >>> > and many developers will make use it (performance!) >>> > >>> > >>> > IMHO lifecycle is better done with annotations, instead of events and >>> > the rest of the lifecycle is already annotation based. >>> > >>> > A problem i have with the current annotation based system is that it is >>> > very static - we have to invent too many different annotation. >>> > >>> > I much more love us to have 1 annotation named @Lifecycle but allow it >>> > to hold a meta value @Lifecycle("PROCESS_ADDITION"), >>> > @Lifecycle("PRE_SHUTDOWN"), ... and we have another invoke on the >>> > ContextInjectionFactory where we pass this meta value. >>> > >>> > Such a feature would be very welcome to implement >>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=392903 which has to >>> based >>> > upon annotation because we need to have a return value, and using the >>> > event system is simply to cumbersom because the event is fired for each >>> > and every element and the receiver has to skip the processing in 95% of >>> > the cases (once more performance!). >>> > >>> > Tom >>> > >>> > Am 07.11.12 20:12, schrieb Eric Moffatt: >>> >> >>> >> While looking at >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=376821I >>> >> realized that we should have some general guidelines for use in >>> similar >>> >> situations... >>> >> >>> >> My general feeling is that we need to be strict(er) about annotations >>> >> since I'm afraid that they'll get out of hand otherwise but I really >>> >> don't have a particular metric in mind for deciding which technique we >>> >> should use. In the case of the defect above the choice was made easier >>> >> since it is clearly a UI Lifecycle event. >>> >> >>> >> Can anybody think of a 'rule' for deciding when we should use one >>> versus >>> >> the other ? >>> >> >>> >> Eric >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >> >> >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
