[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] DirectMenuItem and HandledMenuItem with style CHECK or RADIO
|
Hello Tom, thanks for your answer!
Hmm, so the need arises to introduce a global @Named variable if I want to realize the state sychronization between application model and my code element.
So it seems that the "value-chain" to be sync'ed for the selection e.g. would be
Renderer#MenuItem.isSelected() <-> application model#MMenuItem.isSelected() <-> global variable#filter-male-setting <-> my class#filterForMale
thats for boolean "storage points" needing synchronization.
This seemed to be a lot easier in Eclipse 3.x with the states being available for a command.
At first sight it may be easier to implement Check and Radio buttons using DynamicMenuContribution as it provides the power to steer everything.
Would it make sense to couple the state of a CHECK or RADIO item with a "Persisted State" entry?
Or wouldn't it be a good thing to introduce some advanced methodology for CHECK or RADIO buttons to ease synchronization?
An Addon as you described would be an interesting way, where one could execute stuff like this:
// for check items
?.isSelected(String directMenuItemId)
?.toggle(String directMenuItemId)
?.setSelected(String directMenuItemId)
// for radio items where the returned list is al entries of an associated Radio group
List<MMenuElement> ?.getRadioGroupMembers(String directMenuItemId)
... generally to the moment I find the usage of these elements quite complicated when it comes to coupling the states with the code.
To be honest I do not see the advantage of the Model-Lifecycle in this case, as I would like for the resp. initialization code to be
as "near" as possible to the item itself, not located in some external initialization code.
I propose to create a concept on the usage of CHECK and RADIO as it was realized in 3.x by adding some kind of bindable state or something.
Thanks a lot,
marco
Am 29.12.2012 um 10:32 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>:
> Hi,
>
> I already replied on the newsgroup but let me do here as well. You
> should not use @Execute for this type of things. Currently there's no
> nice solution to the problem but I'd say an addon is the way to go.
>
> public class MyCheckAddon {
>
> @Inject
> MApplication app;
>
> public void valueChanged(@Named("my-special-value") String value) {
> MDirectMenuItem m = ....;
> m.setSelected("A".equals(value));
> }
> }
>
> I think this request can be one more use case for our Model-Lifecycle
> story defined at https://bugs.eclipse.org/bugs/show_bug.cgi?id=392903
>
> Tom
>
> Am 29.12.12 09:54, schrieb Marco Descher:
>> Hello Paul, thanks for your answer!
>>
>> No, the problem is not, that the model item is not in sync with the GUI.
>>
>> Let me explain it with an example
>>
>> Assume I have a filter for a viewer with a DirectMenuItem "Filter Male"
>> of type CHECK.
>> Now during startup I need to synchronize the state of my filter class
>> with the state of the DirectMenuItem (isSelected).
>>
>> If I do not do that, the DirectMenuItem may show isSelected: true while
>> FilterMale is set to false. So I have to set the DirectMenuItem state
>> according to the initial setting of the filter or vice versa.
>> The sychronization I hence talk about is between the application model
>> and my code!
>>
>> So, what and where is the correct e4 style way to do this initial
>> synchronization?
>> In the handler? In a processor? In the part with the viewer?
>>
>> Suppose a the handler (i.e. classURI for DirectMenuItem):
>> At @Execute it is to late, as the item is already presented. It could be
>> handled by
>> @CanExecute, this, however, is called everytime the MenuItem is shown
>> (it however solves the problem).
>> So I thought about @PostConstruct as i is called only once on
>> instantiation and would be a perfect fit to execute the synchronization.
>>
>> This is for DirectMenuItem, for HandledMenuItems I see that in Eclipse
>> 3.x there was a state available to a command which conveyed this
>> information
>> (see http://blog.eclipse-tips.com/2009/03/commands-part-6-toggle-radio-menu.html).
>> But generally the same question arises.
>>
>> Thanks, marco
>>
>> Am 29.12.2012 um 00:57 schrieb Paul Webster
>> <pwebster@xxxxxxxxxxxxxxxxxxx <mailto:pwebster@xxxxxxxxxxxxxxxxxxx>>:
>>
>>> On Fri, Dec 28, 2012 at 4:49 PM, Marco Descher <marco@xxxxxxxxxx
>>> <mailto:marco@xxxxxxxxxx>> wrote:
>>>
>>> I have problems understanding the concept of state synchronization
>>> of the application model with my code for DirectMenuItems and
>>> HandledMenuItems of type CHECK or RADIO.
>>>
>>> The problem is as follows:
>>>
>>> I populate a Menu with either Direct or HandledMenuItems and
>>> except their selection states (in CHECK or RADIO) style to be
>>> according to my code. The problem is that I can't figure
>>> out how to realize this.
>>>
>>>
>>> I'm not sure I follow you. Are you saying that if you modify the
>>> checked model item, it's not reflected in the GUI?
>>>
>>> You can't depend on anything in a @PostConstruct with handler
>>> contributions (handlers for commands or direct contributions) that
>>> isn't available in the global application context. And we recommend
>>> not to use @Inject with handlers in general.
>>>
>>> Instead, you should be able to ask for an MMenuItem in your execute(*)
>>> method. See
>>> org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.getStaticContext(Event)
>>> and
>>> org.eclipse.e4.ui.workbench.renderers.swt.DirectContributionItem.getStaticContext(Event)
>>> for how the model element is supposed to be made available to the
>>> @Execute or @CanExecute.
>>>
>>>
>>> PW
>>>
>>>
>>> --
>>> Paul Webster
>>> Hi floor. Make me a sammich! - GIR
>>> _______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> 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
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
