GWTP Typed Slots

This article discusses the different slots available in GWTP and different use cases for each of them. All examples and code snippets are taken from the BeeStore source code, also available here.

Post_GWTP_Howto_Typed Slots_v1-02

What are slots?

In GWTP, slots are a feature that facilitate the creation of a hierarchy between presenters. They allow you to nest presenters into each other, allowing for child and parent presenters. A presenter is defined as a “child” when it is “set” into the slot of another presenter. Inversely, a “parent” presenter is defined when a child presenter is set into its slot. Such nesting can be useful when, for example, you want to include a widget into an existing presenter, or even when you want a whole presenter to be the child of another.

How to use them

To use a slot, it must first be declared in the presenter defined as its “parent”. Once you’ve chosen the best slot type for your use case (more on this later), you declare it like so:

public static final SingleSlot SLOT_SIDE_PANEL = new SingleSlot();

Then, assuming you have injected the presenter that will be “child” to the current presenter, you call the setInSlot(SLOT_SIDE_PANEL, sidePanelPresenter) method. This method will make the sidePanelPresenter a child of the current presenter. Alternatively, you can call addToSlot(SLOT, presenter) to append a child to the current children of a presenter. However, make sure that you’ve declared a slot that takes multiple presenters as children.

To display the presenter, a container must be declared. Inside the parent presenter’s view, we declare a field that will act as the container: @UiField ReplacePanel sidePanelContainer. Finally, we call bindSlot(ApplicationPresenter.SLOT_SIDE_PANEL, sidePanelContainer) from the parent’s view constructor.

Multiple Slots in a Presenter

There’s no restriction to the number of slots you can declare in a presenter. You can also declare slots with different types without problem. For instance, take a look at the ApplicationPresenter available slots:

Slot Types

GWTP now provides different types of slots for different uses. The generic Slot is still usable, however you can now choose a slot that is more adapted to a specific situation.

SingleSlot

This slot can only take one presenter. This is useful when you want to reserve the slot for specific presenter. For example, this slot is declared in ProductPresenter. The slot is for the PricePresenter which holds the product name and price of a specific item for sale.

static SingleSlot SLOT_PRICE = new SingleSlot<>();

The slot is package-private so it can be accessed by the ProductView but not externally. Calling getChild(SLOT) will return the child presenter.

PermanentSlot

A PermanentSlot is the same as a SingleSlot, the only difference being that once a presenter is added, it can never be removed. This means that getChild(SLOT) will never return null. We used a PermanentSlot for the CartItemsPresenter which holds individual cart items.

public static final PermanentSlot SLOT_CART_ITEMS = new PermanentSlot<>();

Here we’ve chosen the PermanentSlot instead of the SingleSlot because we don’t want the presenter containing the client’s order to be removed.

NestedSlot

This slot is the same as the SingleSlot but it can only take presenters with a proxy. This means that you can’t use PresenterWidgets with this type of slot because they don’t use proxies. In the BeeStore, this slot is used on the ApplicationPresenter which is the root presenter for the application. The NestedSlot is used here so that HomePresenter can be nested into it.

public static final NestedSlot SLOT_MAIN = new NestedSlot();

Other presenters also use this slot such as the ProductPresenter and the NotFoundPresenter.

Slot

This slot is the most permissive of all. It can contain multiple presenters or presenter widgets. You can call getChildren(SLOT) to see which presenters it contains. For instance, this slot is used on the home page of the BeeStore to display the products.

static Slot SLOT_MAIN_PRODUCTS = new Slot<>();

Each product has its own presenter widget created from a factory. Then the widgets are added to the slot on the onBind() method:

A note on Typed Slots

When you need to add different types of presenters to a Slot, you can declare a slot without specifying a generic type. For example, let’s take a look at the SidePanelPresenter:

static Slot SLOT_MAIN = new Slot();

If you need to know what presenters the slot contains, you can call getChildren() which will return a set of all child presenters associated with the slot.

Conclusion

Now that you’ve seen how great slots are for nesting presenters into each other, you can start experimenting with every one of them. Don’t hesitate to take a deeper look at the BeeStore source code, and star the repository if you appreciate it. We did it for you guys!

Feel free to leave feedback or comments in the comment section below.

Live GWT Q&A with Mark Kevin Baldemor on GWT Material on January 19th

We are pleased to announce that we are going to hold our January live Q&A on January the 19th with the founder of Gwt-Material Project, Mark Kevin Baldemor. He is very involved in the community and he will talk about the GWT Material project.

A bit of information about our guest for this month:

“I am currently staying at the northern part of the Philippines with lots of beautiful scenic spots which leads my development life into peaceful and exciting work condition. I tried to help the gwt community and my current company to build rich web / mobile applications with the help of Google Material Design UI / UX specifications which improve the gwt developers productivity. With 3 years expertise on gwt development, I experienced the copy pasting of styles from one project to another, so I decided to create an Open source project api for Front End Framework with the help of Materializecss bringing Material Design to Web Application development with Rich UI / UX and Meaningful Animations.”

Mark Kevin Baldemor

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Code Splitting for Non-Presenters in GWTP

One of the interesting features in GWT is Code Splitting. It allows you to load part of your application only when it is needed. This reduces your app’s loading time and makes for a better user experience.

What is a split point?

Code splitting allows you to separate your code in multiple fragments (more specifically, in multiple JavaScript files). Each location where you choose to separate your code is called a split point. If you want an analogy, each split point is like a door for the content behind it. The main advantage (other than a faster initial loading time) is if a user never accesses some heavy part of your app that is less often used, the total download that the user requires to navigate your app is also reduced.

ProxyCodeSplit

In GWTP, when you want to put one of your Presenters behind a split point, you can use the @ProxyCodeSplit annotation to do it.

ProxyCodeSplitBundle

Sometimes, you want to group some Presenters (“bundle” them) behind a split point. That way, they will be grouped in a unique JavaScript file, which is sometimes more time-efficient than multiple files.

The first thing that you have to do is create an interface with the names of your different bundles, and use the @ProxyCodeSplitBundle annotation. GWT Code Generation will kick off and generate all that you need to separate the Presenters as you wish.

For example, you can write your interface like as follows (taken from Arcbees’ website) :

You can then use the annotation on your Proxy and the name of the bundle you want your Presenter to be in :

Bundles for Non-Presenters

A question that we get quite often these days is how to use this annotation function for Java classes that are not Presenters. These annotations are tailored for Presenters, but not for other use cases.

Suppose we want to bundle two services (FirstService and SecondService) behind a split point. We will have to first create a concrete class for our bundle.

We now have access, via our getters, to each of our services.

Now, if we want to use these services, we can inject the MyBundle class with AsyncProvider (this is necessary for GWT to do its code splitting).

You can now retrieve your service (the best practice is in the onBind() function if you are in a Presenter) this way :

I hope this article helped you understand how split points work, in particular with the non-Presenter bundles. Don’t forget to subscribe to our newsletter if you want more articles like this.

Live Q&A session with Brandon Donnelson on GWT Plugin for Eclipse on December 10th

We are pleased to announce that we are going to hold our december live Q&A with Brandon Donnelson on December 10th.

Brandon will be our guest for this one and he will talk about the Eclipse Plugin for GWT. This Q&A is a great opportunity to learn more about Brandon and the Plugin.

He is really involved in the GWT Community and if you don’t know him, it’s a great occasion to discover who he is. A bit of information about our guest for this month:

  • Brandon is a GXT Support Engineer for Sencha and here is his bio: “I live in Arlington Washington on a small farm with my lovely wife and 5 kids. We’ve got a llama, couple alpacas, some goats and chickens. I enjoy working with the GWT and I like helping others use it for application development. Often in my spare time I’m working on things that help others.”

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Styling Chosen

Using libraries like Chosen is a good way to simplify your code. Otherwise difficult tasks can be completed in a matter of seconds. The main problem we find with libraries though is that their default styles almost never blend well with our own designs, in terms off color, size, shape or something else. Following up on Olivier’s blogpost about how to set up and use Chosen, we will try to fix that styling problem, step by step. If you prefer to read some code instead, have a look at the final application repository.

The basics

Styling Chosen can be achieved by overwritting some classes or simply providing a new stylesheet.

As shown in the default resources file for Chosen, there are 3 stylesheets that can be easily swapped to match your needs :

Chosen also uses a set of icons that you can change, to uzs GSSS Mixins instead.

Changing colors

Creating a custom stylesheet

In this first example, we will create a dark style for Chosen.

Screen Shot 2015-11-03 at 2.37.22 PM

We will copy the default colors.gss, create a new file with it in the CSS resources folder of our project, and call it chosenDarkColors.gss. We will fine tune the colors later, but to be sure that we are loading the new stylesheet, we should change at least one variable. Giving the #000 value for the CHZN_C_PRIMARY variable will do the trick.

Don’t forget to keep the @provide 'chosen-color';, otherwise it will crash.

Creating the associated resources file

In order to make our Chosen widgets use the new colors, we need to provide the widgets with a resources file that will make use of this new stylesheet, instead of the default one.

We only need to mimic the default resources file for Chosen, swapping the color.gss for the one we created, and providing the default files for the rest, using relative paths.

This new resources file then need to be loaded in the application via the ResourceLoader.

Loading the custom style

Now that we have our custom stylesheet and it is loaded into the application, it’s time to tell our Chosen widgets how to use all of this.

In the view file where the widgets are declared (HomeView.java in this example), we will start by creating a variable containing the link to the newly created resource. Then, we will create the ChosenOptions object for our widgets (if it’s not already done) and pass it the new resources. And that’s it!

Go ahead and style! The hardest part – and I can’t help you with this – is choosing the right combinations of colors!

Changing the default style

You can use the same process seen previously in Changing colors to change anything defined in chosen.gss and mobile.gss.  Even better, you can overwrite only the part you want, so you don’t have to duplicate the whole stylesheet.

Conclusion

Styling Chosen is not that hard, in fact it can even be fun! I created an open project on Github with the completed dark style that we started working on (it is an example of the custom stylesheet approach) and, as a bonus, were are including a second color scheme called Unicorn style (you will have to run the application to see it in action).

Have fun styling!

Testing GWTP applications with Jukito – Introduction to Jukito

In this second post of the Testing GWTP applications with Jukito, we present : Jukito!

The purpose of this post is to show the basics of Jukito, and to show what are the advantages for you and for your project.

What is Jukito?

Jukito is a Java library that allows you to reduce the amount of code to write when testing code that is written using dependency injection. Typically, people use Mockito to mock their dependencies and it ends up being cumbersome. Jukito creates mocks for you for all the injected dependencies.

Here is an example made with Mockito and an example done with Jukito.

As you can see, the only differences with the two snippets, are:

  • With jukito you don’t have to call the class under test’s constructor
  • The annotation used to mock dependencies is @Inject instead of @Mock
  • The TestRunner annotation changed

At first, it doesn’t look like a big deal, but when the code base grows, things can get out of control. For example, imagine that we want to add a new dependency to the Endpoint class and inject it via constructor.

With Mockito, this kind of change will produce a compilation error. On the other hand, with Jukito, everything still compiles fine, since the call site doesn’t change.

OK, what now?

Jukito uses Google Guice and Mockito behind the scenes. However, even if you’re not using Guice, you can still use Jukito. The only requirement to use Jukito is to use Java’s standard annotation @Inject on your class’ constructor.

Everything that is possible in a Guice Module can also be done in a Jukito module.

Example

Let’s say you have an interface called UserInformationService. You could have a test that uses a fake implementation, another test that uses the real implementation and another test that uses a mock implementation. By default, Jukito injects Mockito mocks, but it is also possible to bind the interface to whatever implementation you want. To do so, we have to declare a Jukito module in the test class, and setup things there.

There is another cool use case for Jukito and Guice. A lot of Java code use factories. Guice has the ability to generate a factory implementation from an interface. We can either inject a mock factory or create a real factory with a binding in the Jukito module.

The first case would be to inject a mock factory as in the second gist, where we used Jukito.

We had to change the code a little bit here so that the factory would be managed by Guice. As you can see, the scope of the test is a little bit wider. The test verify that the endpoint returns the correct status code.

There is no best solution, it mostly depends on the level of integration you want your test to have. In the first, the response would be the one that you crafted yourself, whereas in the second, the response returned by theResponseFactory would be the same as in production.

Conclusion

In summary, Jukito is a library that does whatever is possible with Mockito and Guice. When writing big projects, it can really help scaling the code base and all its tests.

It is even more useful in a context like a GWTP application, where :

  • Almost all components use dependency injection
  • GWTP uses GIN (which is Guice for GWT)
  • Testing interactions is very natural. Therefore using mocks for testing and driving the design is also natural

Hopefully, this post gave just enough information to understand the upcoming examples about testing GWT components, like Presenters.

Travelling around Europe and launching our school

Post_Arcbees_Europe_V1-01

We’re going to be busy, like really busy, for the next two weeks since we’re going to take part in a couple of events around Europe and try to make as much noise as possible. Our first stop will be Dublin for the Web Summit. This conference promises to gather around 30 000 people from around the world and we have been lucky enough to be chosen to take part in the Alpha program. If you’re at the Web Summit, don’t hesitate to ping me (Christian Goudreau) or Philippe Araujo to grab something to drink (beers!). Our stand is number V-120 in Village Green and it takes place on November 5th so come and see us there!

Post_Arcbees_Europe_V1-02

November 5th is also the date Manon Gruaz will be in Paris giving a conference at her old branding school. It’ll be a shortstop as she’ll be heading off to Nantes for the DevFest organized by Nantes GDG on November 6th. The DevFest gathers around 500 to 600 developers who are excited by Google technologies. Her first conference at her old school will relate her life as a designer in a highly g33k business like ours whereas the one at the DevFest will address the importance of the brand through the user’s experience of your web and mobile application.

Post_Arcbees_Europe_V1-04

Last stop will be in Florence where Manon, Julien Dramaix (who’s now part of the GWT team at Google), and I are going to be the speakers in a community-driven GWT conference organized by GDG Florence. The GWTCon gathers around 150 developers, all interested by GWT and will be the most exciting conference for us as we’re community leaders of the GWT community. My conference will deal with GWT software engineering best practices. Manon is going to give  her conference on brand, but in english this time, whereas Julien will talk about JsInterop.

Finally, on November 13th, I’ll head back home while Manon continues her journey in other countries to travel around the world while working. We also have another Bee that decided to switch to the nomadic life, Philippe, who will stay in Europe and represent Arcbees in the old continent. It’ll give him new challenges, but he has already proven that he was up for it in his previous trips.

Arcbees launches its school!

Post_Arcbees_Europe_V1-05

For  several years, we have been providing training material to several businesses around the world. It was a big requirement for our community to provide more and more public or private courses to help it get started. Since Web Summit is starting this morning, we would like to officially announce that you have been heard and that we have started to improve everything related to documentation as well as training material.

Since July, we hired a dedicated developer who had worked with us in the past and who taught software architecture. Since July, he led the re-write of the documentation initiated by Christopher Viel. He also started a new series of quick video tutorials that you can find on our Youtube channel. Before he joined the team, we had started to release new how-tos every two weeks and we continued to release them consistently.

Today’s announcement is another big step into giving you the best possible training material. The first course will be available in our Bee School. This course is on “how to get started with GWT”. We picked that one on purpose because we found out that there was a lack of professional training material on GWT. The next one will still be on GWT but is going to be more advanced and then, we will do the same thing with our open source offering.

Don’t hesitate to stay connected with us by subscribing to our mailing list. You can also reach us out and share your thoughts!

GWTP 1.5.1 Release

Hi there !

Just a quick note to inform you that we have just released version 1.5.1 of GWTP.

Here are the bugs that we fixed :

  • We made the new NestedSlot removable
  • We made sure that some of the compile errors are not ignored

We also cleaned up the code and solidified some tests to make sure that we follow best practices as much as we can. These changes should not have any significant impact on your GWTP development.

See the full release notes here.

As usual, you’re more than welcome to contribute to the framework or submit an issue if you find one. It motivates us to see that we have a strong community. In this small release alone we have 7 contributors, which is fun and makes us feel that our team is even stronger for their efforts. Thanks for being such a big part of our community !

Don’t forget to subscribe to our newsletter if you have not done so already. We post how-to videos every 2 weeks, and other posts about software releases and topics like organizational culture, whenever we can.

GWTP Beginner’s Tutorial: Toaster Launcher Part 2

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:

Application Structure

This is an overview of the structure that the application will have by the end of this tutorial.

Gatekeeper: Protecting your assets

Post_GWTP_Tutorial_2_V2-01

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.

The @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 @NoGatekeeper on 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

Post_GWTP_Tutorial_2_V2-05

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 PlaceRequest.Builder().

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

Post_GWTP_Tutorial_2_V2-03

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 setInSlot() method.

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 bindSlot() method.

The next time you access the LauncherPresenter, you’ll see the ToasterWidgetPresenter set into it.

RestDispatch: Communicating the RESTful way

Post_GWTP_Tutorial_2_V2-04

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.

Installing RestDispatchModule

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.

Execute

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:

Conclusion

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.

Fly safe.

Subscribe to our newsletter to be notified when the next post comes out!

GWTChosen 3.0.1 Release

A few days ago, we released GTWChosen version 3.0 and made a Q&A about it.

This is a little note to let you know that we have just released the 3.0.1 version which contains fixes for some regressions that sneaked into the 3.0 release.

One of the major things was that the onChange event was not fired anymore, which was obviously pretty important.

Then, we were able to fix our sample on the developer portal and from now on everything should work properly. Please tell us if you see anything that should be fixed or improved in our issue tracker.

Thanks to our active community, we have a lot of eyes on our products. It is thus easier to spot bugs and make a software that is really useful to you!

See the full release notes for more details. Also, if you want to be aware of our future blog posts, you can subscribe to our newsletter.