In the previous article, we laid the foundation for our toaster launcher application. We created a Presenter and a View. We saw how to use UiBinder to declare HTML elements using XML markup. We also used UiHandlers to delegate View events to the Presenter.
In this post, we will continue to build upon that foundation, and start our toaster’s incredible journey into space.
This tutorial will go over the following features:
- Gatekeeper: Protecting your assets
- PlaceManager: Going from one place to another
- PresenterWidget: Reusable controls with their own logic
- RestDispatch: Communicating the RESTful way
This is an overview of the structure that the application will have by the end of this tutorial.
A Gatekeeper is used to protect a Presenter from unauthorized access. The Gatekeeper can be used to prevent revealing unauthorized sections of the application – a login page or an administration section, for example. When a Presenter is protected by a Gatekeeper, the
canReveal() method is called before the Presenter is revealed. If the method returns true, the Presenter will be revealed, otherwise it will not. For instance, this method can be used to verify if a user is logged in.
@DefaultGatekeeper annotation specifies that every Presenter which has a ProxyPlace will be using this Gatekeeper. But what if you don’t want to use the default Gatekeeper on a specific Presenter? The
@NoGatekeeper annotation takes care of that. We’re going to use this annotation in the next example.
Creating the login page
To prevent anyone from accessing the application without authorization, we’re going to create a login page. Now that we know how to create a Presenter, we’re going to create the LoginPresenter:
Here we used
MyProxy interface. We did it to allow the LoginPresenter to always be revealed so that users can enter their credentials. We also stored the user credentials in the Presenter for simplicity. However, this is not recommended in a real life situation. Sensitive information stored on the client-side is not secure. [You’ve been warned 😉 ] We also added a simple validation method for the username and password.
Next, we’re going to create the LoginView and its LoginView.ui.xml twin. I always prefer to create the XML markup first.
By now, if you remember the first tutorial, you should have created LoginUiHandlers and a LoginModule. Don’t forget to install the LoginModule into the ApplicationModule.
Pointing to the login page
Right now the home page of the application points towards the LauncherPresenter. We need to change this because we want the home page to be the LoginPresenter. We can do this by changing the NameToken associated to the default place in the ClientModule.
PlaceManager: Going from one place to another
The PlaceManager allows you to navigate between places in your application. We’re going to use it to navigate to the LauncherPresenter. To do this, we need to inject PlaceManager into the LoginPresenter. Then, all we need to do is to build a PlaceRequest using the
That’s it! After the credentials are validated, the PlaceManager will reveal the LauncherPresenter. The LoggedInGatekeeper’s
canReveal() method will return true and allow the LauncherPresenter to reveal itself.
PresenterWidget: Reusable controls with their own logic
As often happens in a application, you will want to reuse certain UI components – a menu or a form, for example. By using a PresenterWidget for your UI component, you can inject it into any other Presenters.
Creating the PresenterWidget
We’re going to create a PresenterWidget to fetch information about our toaster when it’s out into space.
As you can see, ToasterPresenterWidget extends PresenterWidget rather than Presenter. It also doesn’t have the
MyProxy interface you’d declare in a regular Presenter. Associating a View to a PresenterWidget is done the same way as regular Presenter. So we are going to skip this part. You can always look at the github repository if you want to see exactly how we did it.
Setting the PresenterWidget in a Slot
PresenterWidgets need to be set in a Slot which serves as a placeholder for them. Theses slots are defined in a Parent Presenter. Look at the documentation for the right type of slot to use in your application. In this case, we’re using the regular Slot which is the most permissive. To set the PresenterWidget into the slot, we use the
Binding the Slot to a container
The next step is to bind the slot to a container in which the PresenterWidget will be displayed. This is done on the Parent View. When the container is defined, it can be bound to the Presenter’s Slot using the
The next time you access the LauncherPresenter, you’ll see the ToasterWidgetPresenter set into it.
RestDispatch: Communicating the RESTful way
REST is everywhere nowadays and GWTP has a client library to communicate with a server in a RESTful way. RestDispatch can be used without GWTP which makes it great for any GWT application. Before you can send data over the wire, your object must be serializable. RestDispatch uses Jackson to serialize to JSON. Because if this, you have to either use
@JsonCreator on your constructor or use a no argument one. For this tutorial, we’re going to use the no argument constructor. We also assume that you have read the documentation on how to add RestDispatch to your pom.xml and make your GWT module inherit from it.
We are going to use RestDispatch to make requests to the external API. The first request we’re going to make is for the toaster launch. It will send a POST request to the API with the coordinates and power parameters. The second is a GET request that will retrieve information about the toaster.
Creating a resource
Let’s start by creating a ToasterResource for RestDispatch to use.
RestAction<R> will take care of deserializing the response and returning an object.
The next step is to create a Gin Module to install the RestDispatchAsyncModule and bind the RestApplicationPath to the server API endpoint. This module will also need to be installed into the ClientModule.
To execute a request, we need to inject RestDispatch and ToasterResource into the Presenter. Then we call the
execute() method to send the request.
This is the launch request from the LauncherPresenter:
And finally, here’s the getToaster request from the ToasterWidgetPresenter:
The Brave Little Toaster can now fly freely out to deep space, and surely you can too start your own GWTP adventure. I hope that what you learned in this tutorial will help you in your future GWT applications. Feel free to comment on this post or on content that you might like to see in a future post.
Subscribe to our newsletter to be notified when the next post comes out!