On 03.03.17 16:47, Andreas Sewe wrote: > Hi Tom, > > thank you for you insights. > >> I'm sorry if the next few line will add even more to your frustration >> because what you are doing here is just plain wrong :-(. > >> Abuse of @CanExecute >> -------------------- >> You are abusing @CanExecute for something it is not designed for. First >> of all @CanExecute sole purpose is to control the enablement/disablement >> of a command - point. > > I get that. That's why I wrote that using "Using @CanExecute for this > seems like a hack, as I don't really determine the handler's executability". > >> You further assume that the command is bound to a MMenuItem but it might >> as well get bound to a keybinding, toolbar item. > > In this case, no. I am talking about a *Direct* Menu Item here, so > MyHandler is not a real Handler (in the Applicaton Model sense) but just > some class with an @Execute method. >
A handler is a generic thing, you just bind it to an MDirectMenuItem today but to another Handler tomorrow. A handler is a stateless thing who has to purposes: * compute the enablement * execute the action >> The correct solution: >> --------------------- >> The correct solution is to use an Addon who listens to the preference >> change, querys the model to find the required MMenuItems, ... and >> setting the check-state of the MMenuItem. Your handler should never ever >> access the MMenuItem, MToolBarItem it should just flip the preference >> (as I said it might get triggered by a keybinding!) > > *If* I had a *Handled* Menu Item, then the key binding thing is indeed a > problem. Note, however, that I could just ask for an MItem, which is > very generic (but still doesn't exist in the key binding case). > but there even isn't a MItem then, the @CanExecute won't be called and your Handler state is just wrong, at least it has to be @Optional but I repeat it is NOT the handlers job. >> Look at [1] where I do something like that in efxclipse application, it >> uses our preference story and does some more complex things but i think >> you get the idea. > > So you are essentially saying that I have to implement an add-on that > maintains some kind of preference -> tag mapping and then, whenever a > preference changes, looks for all model elements with the corresponding > tag and updates their selection state. Right. > > This quickly gets ugly if we are talking about multiple preferences: The > addon would need an @Inject @Preference method for each of these > preferences. At the same time, the different handlers would still need > to know about the preferences as well, as their job is to change their > respective preference. Having to spread this logic across several > classes doesn't feel very elegant. > Who says you can't make this stuff generic? You just would not use @Inject but eg a PreferenceListener. Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck _______________________________________________ e4-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
