Re: [e4-dev] Feedback from a frustrated user on the @(Can)Execute API

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

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