Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Feedback from a frustrated user on the @(Can)Execute API

Hi Tom,

first of all, thank you for taking the time to answer my questions. I've
read through the Eclipse 4 book by Teufel and Helming and most of
Vogella's tutorials, but they mostly stop short of these topics (what
addons or processors are meant for, how to keep the Applicaton Model and
your application's state in-sync, etc.).

You wrote:
>>> Abuse of @CanExecute
>>> --------------------
> 
> 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

Understood.

>>> 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!)
>>
>> 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.

Yes. But I'm afraid I still don't understand what addons were supposed
to do. The ready-made addons all deal with rather low-level
functionality like min-maxing views, so it simply didn't occur to me
that addons can (and should) be used for higher-level functionality as
well. But come to think of it, the more generic you make your addon, the
more "low level" it becomes.

So, to summarize, you recommendation is to ...

... make the handler simply toggle the boolean preference, without
reference to any Application Model element in its @Execute method, and

... create a generic addon that listens to any changes to (boolean)
preferences with $ID and then searches for MItems in the application
model with tag $ID, changing their selection state accordingly.

This sounds like a good design.

The only piece of the puzzle I don't get yet is how the MItem's
selection state gets initialized, since I don't get preference change
events for the initial values. Somehow, the addon needs to enumerate all
MItems in the Application Model, look for any preference ID in their
tags, consult the preference store, and set their selection state
accordingly, correct? But when is the right time for this
initialization? In the addon's @PostConstruct? Or is this too early,
i.e., won't the model be populated with all MItems yet. Maybe this is
what processors are meant for (as opposed to addons)?

I hope you can help me clear that last bit of confusion as well. Thank
you in advance.

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Attachment: signature.asc
Description: OpenPGP digital signature


Back to the top