Community
Participate
Working Groups
Build Identifier: This is a sub entry for bug 335691. It provides annotations that may me used to mark an arbitrary controller method as a handler of a specific event fired by a specific ridget. I.e. instead of writing controller code like this (example from o.e.r.e.c.c.ComboAndChoiceSubModuleController) updateAllRidgetsFromModel = getRidget("updateAllRidgetsFromModel"); updateAllRidgetsFromModel.addListener(new IActionListener() { public void callback() { updateAllRidgetsFromModel(); } }); within the #configureRidgets method you would just annotate an arbitrary Method (performing the same logic, of course) with the information upon which event on which ridget it should be executed: @HandlesActionCallback("updateAllRidgetsFromModel") public void handleUpdateAllRidgetsFromModel() { updateAllRidgetsFromModel(); } Note that the assignment of the ridget to an instance variable is not needed anymore. The event to be handled is identified by the annotation type (@HandlesActionCallback) and the is identified by its name provided as the value parameter to the annotation. The registration of the event handling methods takes place after the ridgets are injected into the IRidgetContainer but before the #afterBind method is called. The methods must be public members of the IRidgetContainer containing the ridgets whose events are to be handled. The may optionally contain a single parameter which if given must be of the appropriate event type (eg o.e.r.u.r.l.SelectionEvent etc). The patch contains the following annotations: - @HandlesActionCallback - @HandlesFocusGained - @HandlesFocusLost - @HandlesPropertyChange - @HandlesSelectionChange The @HandlesPropertyChange annotation is different in that it may require a second parameter to contrain event handling to a certain property: @HandlesPropertyChange ("name", "text") This second parameter is optional - if left out the event handler gets called on all property chanded events. The known annotations are configured using an extension point, so you can add your own event handler anotations for your custom ridgets. The needs to be a corresponding handler implementation for each extension. Have a look at org.eclipse.riena.ui.ridgets.swt.uibinding.handler.ActionCallbackAnnotationHandler for an example. The event handler registration is performed by the o.e.r.u.r.s.u.DefaultSwtBindingDelegate. Please have a look at the implementation and share your thoughts with us. Reproducible: Always
Created attachment 187946 [details] Annotations for action and selection listeners o.e.r.e.c.c.ComboAndChoiceSubModuleController and o.e.r.e.c.c.ListSubModuleController from the org.eclipse.riena.example.client plugin have been changed to use annotation for action and selection listeners
I fully second that enhancement! It would make controllers so much more readable and easier to develop. Please consider improving the patch for the following use cases: 1. Provide a default annotation for double clicks in a list or table. AFAICS this is a common use case. 2. Provide a possibility to attach a listener to multiple ridgets. As an example, it might be useful to do some UI updates when one of multiple ridgets looses focus.
in reply to comment #2 1) yes 2) If this can be done by annotating a 'listener' method with multiple annotations each with a different ridget id - would that be ok?
General question: How specific or how general shall annotation handlers be? E.g. the handler responsible for 'addListener(IActionCallback)' performs the 'addListener' on just IActionRidgets. Shall it also perform that action on any kind of ridget supporting this signature? In this case also for ITraverseRidget? Maybe use duck typing!?
I am against duck-typing since that means using reflection. But I would be PRO having that annocation for IActionRidget and ITraverseRidget.
Thanks Holger! Patch applied with a few refactorings. in reply to comment 4: NO duck typing!
I was just trying to use this new, very cool feature but sadly I can't use it for all use cases I was hoping for. As described in comment#2 I'd like to use it, among other things, to react to change events and trigger an UI update: @OnPropertyChange(ridgetId = BINDING_ID_RIDGET1) @OnPropertyChange(ridgetId = BINDING_ID_RIDGET2) public void doUiRefresh() { [...] } I guess that's not possible but it would be nice to be at least able to provide a list of ridget IDs. Otherwise one would have to fall back to "the old ways" in this case. I guess the same goes for all other annotations.
Reopened because of comment #7
Yes, this is very sad. Unfortunately Java does not allow this. However, there are common patterns (requiring additional coding) to solve such issues. 1. Nested annotations, e.g. @OnPropertyChanges( { @OnPropertyChange(ridgetId = BINDING_ID_RIDGET1), @OnPropertyChange(ridgetId = BINDING_ID_RIDGET2) } ) public void doUiRefresh() { [...] } 2. Allow multiple values (array) for ridgetId (would become ridgitIds) @OnPropertyChange(ridgetIds ={ BINDING_ID_RIDGET1, BINDING_ID_RIDGET2 } ) public void doUiRefresh() { [...] } 3. Allow the mutliple values be expressed within a single comma separated string @OnPropertyChange(ridgetId = BINDING_ID_RIDGET1 + "," + BINDING_ID_RIDGET2 ) public void doUiRefresh() { [...] } I would go for solution 1. since this is the most flexibel and obvious solution.
I too would prefer solution 1, since the other ones become unreadable if an additional parameter needs to be provided (e.g. propertyName for this @OnPropertyChange).
(In reply to comment #10) > I too would prefer solution 1, since the other ones become unreadable if an > additional parameter needs to be provided (e.g. propertyName for this > @OnPropertyChange). I could agree if we agree that the unnested version for one ridget continue to exist. That the 80 % use case and I would hate if I had to write a nested annotation for that simple use case….
(In reply to comment #11) > I could agree if we agree that the unnested version for one ridget continue to > exist. That the 80 % use case and I would hate if I had to write a nested > annotation for that simple use case…. Of course, do they still exist! They are part of the outer "container" annotation. All of the "ridget"-event annotations will get a corresponding "container" annotation with the same name in plural.
Created attachment 191859 [details] OnActionCallbacks annotation
Added annotations (suggestion 1)and handler as described in comment #9
