Community
Participate
Working Groups
If views show complex data it might be a good choice to actually disable certain functions if the part is not visible (e.g. another tab is hiding it). The proposal is to have @Suspend / @Resume annotations that behave the following way: - whenever a part is minimized or a tab is become hidden (e.g. another one is selected) a method annotated with @Suspend is called. - whenever a part that previously was minimized or hidden (e.g. in a ctab) a method annotated with @Resume is called. this would allow to suspend/pause for example side effects or tracker.
Wim, didn't you do something like this in the past?
(In reply to Christoph Laeubrich from comment #0) > If views show complex data it might be a good choice to actually disable > certain functions if the part is not visible (e.g. another tab is hiding it). > > The proposal is to have @Suspend / @Resume annotations that behave the > following way: > > - whenever a part is minimized or a tab is become hidden (e.g. another one > is selected) a method annotated with @Suspend is called. > - whenever a part that previously was minimized or hidden (e.g. in a ctab) a > method annotated with @Resume is called. > > this would allow to suspend/pause for example side effects or tracker. That is a nice idea. I always call the framework to know if I am visible in a selectionchanged situation which is boilerplate @Suspend could take away. For menus, we currently have: @AboutToHide/Show I think the @Resume, although slightly different, is covered by @Focus? (In reply to Lars Vogel from comment #1) > Wim, didn't you do something like this in the past? I did but using existing API ^^
(In reply to Wim Jongman from comment #2) > That is a nice idea. I always call the framework to know if I am visible in > a selectionchanged situation which is boilerplate @Suspend could take away. The bad thing is that one don't get notified afterwards when the view becomes visible again. Thus an @Resume could recover from that state then without the need to have special code for it. > > For menus, we currently have: @AboutToHide/Show > > I think the @Resume, although slightly different, is covered by @Focus? @Focus is different I think as for example I can have two views, both are visible, every time I select one of them it revives the @Focus @PostConstruct on the other hand is only called when the view is created the first time (what already has some logic to not create views that are currently not visible) @Resume would be something in between, notify the view that is has become visible again (without close/recreate) it.
+1
Speaking of existing API, in the E3 implementation there must have been lots of though on the lifecycle of a Part. Please consider all lifecycle events that are defined in IPartListener/IPartListener2 (and the E4 IPartListener) and how these map to annotations on E4/POJO, if they are relevant. In PartServiceImpl activate, you can see that activate/bringtotop/focus all have slightly different semantics (a part can be brought to top without being activated, when a part is activated it can optionally get focus). Also, I see that there are the E4 UI life cycle events UIEvents.UILifeCycle.BRINGTOTOP and UIEvents.UILifeCycle.ACTIVATE, which are related too. Clearly defined and documented lifecycle stages of parts, with mapping on E3/E4 events and annotations would be helpful.
