Skip to content

Presenter dependency

Ahmad K. Bawaneh edited this page Nov 7, 2021 · 1 revision

In an actual application we will have more than just a single presenter, and those presenters sometimes needs to depend on each other, for example items list presenter will need the layout to be already active and revealed, so it can reveal its view in the layout content panel, or a presenter needs to wait for another to be activated and update some context, when we have such case we use different approaches to make such dependency work :

  • Parent/child dependency

When we define a presenter/proxy we can give it a name, then we can use that name to define another presenter/proxy parent, when a presenter has a parent it will not be activated unless its parent is activated, and same as slots presenters that has the same name will be registered in a stack style, meaning a child presenter does not care which presenter is actually activated as long as it has the same name.

Example :

@PresenterProxy(name = "shell")
@AutoRoute()
@Slot(PredefinedSlots.BODY_SLOT)
@AutoReveal
@RegisterSlots({Slots.LEFT_PANEL, Slots.CONTENT})
public class ShellProxy extends ViewBaseClientPresenter<ShellView> {

}
@PresenterProxy(parent = "shell")
@AutoRoute(token = "home")
@Slot(Slots.CONTENT)
@AutoReveal
@OnStateChanged(HomeActivationEvent.class)
public class HomeProxy extends ViewBaseClientPresenter<HomeView> implements HomeView.HomeUiHandlers {

}

In this example the home proxy will not be activated until the shell proxy is activated.

  • Event dependency

The activation of a presenter can be made so that it depends on events being fired, all such events needs to extend from ActivationEvent and the presenter can depend on one or more events to be fired, we define such dependency using the @DependsOn and @EventsGroup annotations :

import org.dominokit.domino.api.client.annotations.presenter.DependsOn;
import org.dominokit.domino.api.client.annotations.presenter.EventsGroup;

@PresenterProxy(parent = "shell")
@AutoRoute
@Slot(Slots.CONTENT)
@AutoReveal
@DependsOn({
        @EventsGroup({UserLoggedInEvent.class, AuthenticationEvent.class}),
        @EventsGroup(UserLoggedOutEvent.class)
})
public class NotificationProxy extends ViewBaseClientPresenter<HomeView> implements HomeView.HomeUiHandlers {

}

In this example the presenter will not be activated unless either both of UserLoggedInEvent and AuthenticationEvent are fired or UserLoggedOutEvent is fired, the events in the same group must all be fired but at least only one event group needs to be fired to activate the presenter, - events in same group uses AND while between groups it is OR -.

And as we discussed in presenter state events, presenter can auto fire presenter state events, and we make other presenters depends on those events, we actually make them depend on those presenters.

  • Manual dependency

Knowing the life-cycle of presenters and knowing how we can actually do routing for presenters , we can always make presenters depends on other presenters by manually firing events, change the URL token or even manually trigger other presenters commands.