Testing patterns in GWTP

This post is intended to be the next steps towards a TDD approach with GWTP. We’ll try to show you the patterns and workflow of writing a GWTP application in a TDD fashion. Continue reading “Testing patterns in GWTP”

3 Steps to Make your Culture Unique

Three months ago, we published our first blogpost which dealt with our will to define our culture and questioned what initiatives we could set up to help us fulfill our goal. Since then, we took  a further step  in our journey, and this post  is meant to show you the progress we have made so far.

In the last post, we introduced our 9 values. We could have simply stopped with these and tried to put them directly in use or just listed a number of adjectives such as collaborative, innovative or passionate… But at the same time, it does not define who we are and what makes us  unique.

– If you want to be able to find your DNA, you have to dig deeper, you have to go further in defining your culture –

Our first step was to define the values. We knew our journey to define our culture was supposed to go beyond that. The next step was to create the manifesto in itself.

What is the Arcbees’ Culture Manifesto?

The Arcbees Culture Manifesto is a written statement of all Arcbees’ employees regarding our culture and the way they see the organization as a whole.

We went through three steps to define it.

Step 1: Dig deeper, wrap it up and name it

In the previous post, I mentioned how we took the necessary step to obtain everyone’s list of values. With those values came an explanation about what it meant for them.

Make them match: Collecting those explanations and making them work together was the hardest part and the list of values came from the best of each one of us. But then, we needed to find a way to explain each value so that it could resonate in everybody’s mind.

I took each one of those explanations and put them in a single document to try and find the words and ideas which were most common.

Don’t interpret! This step is rather a long process. The objective is to not transform or interpret what a person is saying. One has to take the explanation, try and make it match with the right value and match it with the others.

For the most popular values, we received 7 or 8 explanations coming from the 12 Arcbees’ employees. It means 8 ways to explain it, 8 ways to name it, 8 different lexicons and 8 unique minds behind it.

Take your time and dig deeper: It took me time to wrap up and summarize what people wanted to say, to find the essence in each one. I asked questions to try to understand what they meant behind each sentences.

You are not Superman! I want to warn you already about something. It is not a one man job as you need inspiration from others to find the right words and find the right flow in the sentences. At Arcbees, one of our principal values is collaboration and this manifesto is a collaborative work.

At the end, we wrapped it up and came up with a list of 9 values:


Step 2: Share with the team and gather feedbacks

Once everything is ready with the manifesto and you wrote a 0.8 version, it’s time to start to get feedback from the team.

Feedback process We prepared a presentation for the team and scheduled a meeting to have everyone present at the same time. The point was to have everyone’s reaction in person.

We introduced each value and its explanation. We then gathered the comments we received on things such as titles or the words used on the explanation itself.

Appropriation begins… At this part, you will notice people starting to appropriate the different values. Some of them stay more than others. You will witness strong reactions, which is good!

After the meeting, each person read it again and gave their own comments. Sometimes directly to me, sometimes by using Slack to have a discussion all together on a particular value.

Getting things ready for the final step The final request was for everyone to rank the values by priority for them from 1 to 9. This ranking would help us determine in a collaborative way which value was the most important at Arcbees.

Step 3: Plan to make it alive

Once the final document was made and we obtained the ranking for each value, we able to start our next step. This ranking has created a plan for further work around the manifesto.

– The goal of this exercise is to make your culture unique and your company! –

One word: Focus!!! We decided to focus on one value per month to accomplish step 3. We are going to apply the same recipe as for our other projects: an agile methodology inspired from Scrum. We want to use it to implement our values. By doing sprints lasting one month, we will define more specifically what is the value and actions inherent to it.

Each month will start by a brainstorm session. This session is open to all, and everyone can bring these ideas about the value we are focusing on.

At the end of each month, we will conduct a retrospective of the past month and the work done around the value. These tasks will eventually enrich our manifesto.

We are going to continuously do this work and improve our values ​​and our manifesto.

We will keep our communities updated with our progress. In February, we will focus on the value “We believe in the individual.”

Follow us: Subscribe to our newsletter, or on social media (Facebook, Twitter, Google+) if you want to follow up on the story of our commitment to our culture.

Using GWT 2.8 beta 1

EDIT : An earlier version of this post talked about Java 8 Streams, which are not supported by GWT 2.8 for the moment. My apologies.

A few weeks ago, the GWT Team released on Maven a beta for the new version of GWT: GWT 2.8 beta 1. This new version has been announced for a while and was eagerly awaited by the community.

Other than speed improvement and many cool new enhancements, there are new features we can now use in our GWT application. One big feature of this version, in my opinion, is the support of lambdas, a part of Java 8.


In Java 7, if one wanted to pass a function in parameter, they had to do something like that :

In Java 8 (and also in GWT 2.8), simply do this:

We now have a more elegant way to write exactly the same functionality. It makes for more compact code, with less clutter and cleaner code.


Another thing to note, the interoperability with JavaScript is no more experimental. You can now simply use the annotations (@JsType, @JsProperty, etc.) and directly use a JavaScript library in your GWT code.

As Brendan Donnelson said in his Q&A, you can now imagine – if you have a GWT and JavaScript expertise in your business –  a seamless collaboration between JavaScript developers who do part of the application and GWT developers who use their work in the GWT application.

For example,

This example was taken from the current specification of JSInterop which covers a lot of the possibilities of JsInterop. It is also possible to make content in Java that could be exported and usable in JavaScript. A few of our developers are currently exploring on both sides of this coin. I think it will make for good next articles on this blog.

Concrete example

If you want to see concretely what a migration to GWT 2.8 beta1 is like on a typical GWT 2.7 application, just refer to this pull request. I am currently in the process of moving our BeeStore sample to GWT 2.8. It will give you an idea of how to do so.

We just covered the tip of the iceberg of what is new in GWT 2.8. See the complete release notes for the complete list of features that GWT 2.8 beta 1 brings.

Feel free to tell us what cool web application you did (or plan to do) with GWT 2.8 or JsInterop in the comments!

Live GWT Q&A with David Chandler on GWT 3 and the Sencha GXT roadmap

We are pleased to announce that we are going to hold our February live Q&A with David Chandler on February the 10th..

David Chandler will be our guest for this one and he will be discussing the upcoming changes in GWT 3 and how it fits with the next version of Sencha GXT.

David was formerly the GWT Developer Advocate with Google and is now GXT Product Manager and Developer Advocate with Sencha, Inc

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+).

Return on Kevin’s answers on live Q&A on GWT Material

As you may know, 4 months ago we decided to put in place a new initiative for the GWT community. We wanted to highlight what was happening in the GWT community and start sharing the knowledge.

We held 4 Q&As already, which you can watch here. In preparation of those Hangout on Air events, we prepared a series of questions for our guests.

We know that some of you don’t have the time to watch a 30 min. video, this is why we took notes during the event.
You will have a hint of the live event which you can watch below:

Mark Kevin Baldemor was our guest for this Q&A and he talked about GWT Material. Founder of the Gwt-Material Project,he has been involved in the community for three years now.

Phil: Who are you and what do you do?
Kevin: I am Mark Kevin R. Baldemor, I’m currently staying in the northern part of the Philippines, surrounded by oceans and tall mountains with different species of wild animals. I am now 21 years old and I graduated at Informatics College Philippines with an Advance Diploma on Multimedia Technology in the year of 2013. I have my Internship at BPM Conseil, a french company located in Lyon, France and luckily I did my first job there with the introduction of GWT Technology, HIbernate, OSGI and lots of Google API’s. I do web and mobile development using open source kits like Android SDK and Phonegap. After my work life with BPM, I continued my journey to develop my own open source GWT Ui Framework built Material Design called “GWT-Material”.

Phil: What company are you working for? Can you tell us more about it and your role there?
Kevin: Now, I am working for I3 (Canadian Company) – on the IT Department as a Gwt UI UX Developer and a Project Owner and Contributor of gwt-material open source project.

Phil: Some questions about GWT first: When and why did you start using GWT?
Kevin: I started using GWT on 2013 from version 2.5 to 2.8. I loved the architecture pattern of GWT using RPC to communicate with the Server side components. Then, I tried to make some sort of starter projects using GWT for front-end and Hibernate for the back-end which makes the development process more exciting. As a result, I did more and more projects inside my company and the result was very nice but there was a code duplication when I included the CSS, JS Resources to build a custom widget. That’s when I tried to learn how to build a UI Framework and hosted it on Github with the help of other GWT Contributors to make it more Modular and easy to integrate to other projects.

Phil: Now about GWT Material in itself, you are the founder of this project. When and why did it start?
Kevin: Yes I am the founder of this project. It was founded January of 2015 with an alpha version hosted on Google Code, but later on with the help of other GWT Contributors, we tried to host the project on Github and released a Maven version (1.0) which improved the productivity of the project plus the showcase app. The history of this project started when Google announced their design language called “Material Design” and I discovered Materializecss (a CSS Framework) founded by Mr. Alvin Wang and his team. They wanted to build a website using the design specification of Google. With the whole idea, I finally decided to create an open source Apache 2.0 license GWT Based widgets built in Material Design specifications called “gwt-material” and I added some custom components and called them “gwt-material-addins”, like Autocomplete, Time Picker, PathAnimator, Subheader and etc.

Gilberto Torrezan Filho: Talking about GWT Polymer, doesn’t GWT Material have the same purpose as Vaadin’s project? Will they be competitors to each other in the future?
Kevin: GWT Material is totally different from GWT Vaadin Polymer project, because our project is totally based on GWT widget based systems built on Material Design Specifications and with the help of Materializecss contributed by Avin Wang. GWT Vaadin created their generator api to create paper components using JSInterop, soon on GWT Material we will also implement those features using Elemento and JSInterop to support GWT 3.0.

Zakaria Amine: Is GWT material design library production ready?
Kevin: Yes it is production ready, and honestly we have news coming from the community: they have successfully built a gwt-material design application on Web and also on mobile development using Phonegap. We also provided templates for a guideline on how to develop using gwt-material.

Below are the list of applications built by the community for their personal and company projects:

  1. TripWeGo by Julien Guibert
  2. Healthphere by OrNot (Github username) – http://www.healthphere.com/
  3. MyMoney by Werner Kok

Here are also the list of the templates we provided :

Phil: Question # 5 : What can you tell us about the community?
Kevin: About the community, we have now 118 members on Gitter Channel, 116 members on Google Plus and 128 Stargazers on Github which is a good news for the project itself. Many users submitted their Pull Requests for new exciting material design widgets. Some are submitting issues which improves the stability and quality of the project. GWT Material has 9 members, some are part time contributors and others are actively contributors of the project. Thanks to Ben Dol (New Zealand) on the huge code refactoring made on 1.4 release including the modular theming of the project called “gwt-material-themes”. For the Maven releases of the project, Christian Lacerda (Brazil) is our active releaser for the said project. Sometimes we organize online session using Team Viewer to help one another on how we can leverage and discuss about the project.

Phil: Question # 6 : What can you tell us about it and its evolution?
Kevin: GWT Material is a Material Design based widgets with the help of Materializecss as core framework. We release

  • 1.0 for the (Production Release) it includes the core material widgets.
  • 1.2 Integration of Phonegap plugin with gwt-material
  • 1.3 Maven Official Release
  • 1.3.1 Bug fixes for 1.3
  • 1.3.2 gwt-material Themes
  • 1.3.3 Material Design templates
  • 1.4.0 Huge Code Refactoring
  • 1.4.1 Bug Fixes for 1.4 (Upcoming)
  • 1.5.0 gwt-material-addins components (Upcoming)

On each release we are very thankful to the contributors for their support on gwt-material project. I am very happy that until now the project status is still actively maintained.

On 1.5.0 version, we added MaterialPathAnimator to provide meaningful and delightful animations to transform a source widget into target widget. It helps the users to not loose their interaction between two components e.g a Card transforms into an overlay panel or a button transforms into a card. Also we tried our best to implement core animations like fade in/out, slide in/out or even page transitions into the Material Design widgets. We also added a built in Google Icon Fonts hosted internally and we provided a morphing animation using MaterialIconMorph.

Mohammed Al-Hammouri: What about the performance or size of the library?
Kevin: First, I’m not really good on performance optimization about web applications, but for the css or js resource, files of Materializecss can be measured using their jasmine test. Now, I am developing some big applications and the result is great, it is fast. I don’t have any issue on app’s performance including the server side and populating the data into a specific material design view component. On Phonegap, I tried to integrate my web app but it seems to be too slow because of the JQuery animation plugin which kills the performance. What we did is that we separated the modules into different repositories like gwt-material-theme and gwt-material-addins so that the user can choose whether they want to have only the core components or include the addin components.

Gilberto Torrezan Filho: Materialize CSS is the base project for GWT Material, but currently GWT Material have more components than Materialize CSS. How is the relationship between Materialize CSS and GWT project teams? What would happen to GWTM if materialize CSS is discontinued?
Kevin: This is a good question. I talked to Mr. Alvin Wang about the project and he was happy that their project was used by GWT Material. As for me, I am very thankful for their contribution to the world of web development. If Materializecss were to be discontinued, it is likely that we would have already created our Plan B: “gwt-material-addins” – a collection of custom Material Design Widgets plus Community contribution built in pure gwt-material widgets.

Phil: Question # 7 : What is the future of the GWT Material?
Kevin: This is a good question. As for now, we all know that we are waiting for the GWT 3.0. Everything is new as I heard on the GWT community, such as the usage of JSInterop, Java 8, Web Components and other tech behind it. With gwt-material 2.0, we are thinking about implementing all of these inside the project to provide a bullet proof support for the said open source project to make gwt-material a great project and supports GWT 3.0.

Also we are trying to build more Material Design Widgets and trying to refactored it using JSInterop. We are on the Research and Development process to learn how to use it and provide the architecture of GWT Material 2.0 and will be able to release on Maven Central as soon as possible.

Martin Hollerweger: How do you see the future with GWT and js-Interopt? What are the main benefits of GWT compared to other solutions like ionic?
Kevin: The future of GWT and JSInterop is interesting but it has a minor effect. First with the use of UiBInder and widget system: these features will be removed on GWT 3.0, I think. But for gwt-material, we will try our best to support it using JSInteropand Java 8 other features. For the last question, sorry but I don’t have any idea about Ionic.

Martin Hollerweger: Will Gwt-material switch fully to js-interopt?
Kevin: This will depends on the discussion with the community. If they want to switch fully to JSInterop then we will do it for them but in my opinion as a founder, it is good to have backup plans to anticipate the migration such as creating an old branch to backup the previous features that does not support JSInterop. Then, we will create a new branch for the JSInterop migration so that the user will have options if they want to switch their apps into JSInterop support or not.

Project shared
GWT Material repository – https://github.com/GwtMaterialDesign/gwt-material
GWT Material Addins – https://github.com/GwtMaterialDesign/gwt-material-addins
GWT Material Themes – https://github.com/GwtMaterialDesign/gwt-material-themes
GWT Material Showcase – https://github.com/GwtMaterialDesign/gwt-material-demo
GWT Material Phonegap – https://github.com/GwtMaterialDesign/gwt-material-phonegap
Google Plus Page – https://plus.google.com/communities/108005250093449814286
Contributing Guide – https://github.com/GwtMaterialDesign/gwt-material/wiki/Contributing

4 Rules of Simple UI Components

Too often have I seen simple web applications become a huge pile of intertwined, indecipherable JavaScript code. As features are added, code is added into seemingly random files, event listeners are accidentally duplicated, jQuery selectors stop working because someone moved the DOM around one too many times and sooner or later you start to feel the consequences.

It fails randomly.
It breaks in strange places.
It has regression bugs.
And no one wants to change it (for fear that it will become their code!).

Chaos and pain ensues. From my experience, the code becomes complicated way before the interface becomes complex. I know very few truly complex user interfaces, but the internet I browse is an endless stream of complicated JavaScript code. Sometimes, I look at the source code just to amuse myself. Sometimes, I even do so before applying for a job. Uh oh.

How did the web become a breeding ground for both simple interfaces and complicated code? To make things worse, this complicated code is located in a codebase that changes all the time! It is very hard to get an interface right in a one swift commit. It requires successive refinement based on customer feedback. Although this code changes all the time, it is often the hardest part to maintain.

Maybe it is our infatuation for cool new JavaScript frameworks that led us astray, but we seem to have lost basic software craftsmanship practices.

Corey Haines wrote an awesome book called Understanding the Four Rules of Simple Design based on Kent Beck’s 4 rules of simple design, which I highly recommend. Inspired by this book, I tried to distill UI complexity and found 4 rules of simple UI components that should help us write better, simpler interfaces. This is nothing new, but somehow it seems to have been forgotten along the way.

Rule #1: Break it down into named components

Thou shalt not underestimate the power of good naming

Break it down into named components

This is the simplest, yet most powerful rule of software design. Whether it is to discuss with the client or to understand each other when saying “the thingy” broke, good naming has the virtue of bringing people together. Picking a good name today might even help your colleague better decouple code in 6 months. This is what Corey Haines calls behavior attractors in his book. It is easier to see where your new code should go when things are properly named.

For UI design, this boils down to sitting with the client and figuring out a name for each thing. What is this portion of the page called? This new kind of input, what should we call it? Name small things, agglomerate them, then name bigger things! If you want, you can follow principles from Brad Frost’s atomic design, which is a good starting point. Instead of saying “the blue bar in the viewer thingy is overlapping with the other side”, you could say that “the document toolbar in the patient history viewer is overlapping with the annotation explorer“. Once the vocabulary is agreed upon, this makes your code less prone to bugs and misunderstandings with the customers.

In order to name components, you must break them down to a manageable size. If not, you maybe end up with names that include multiple “and’s” or end with “Util”. Be careful to name components according to their level of abstraction. If you name something “Intervention Plan”, I expect it to be high level and be broken down into smaller components. Maybe an “Intervention Plan” is made up of “Observations” and “Directives”. Maybe “Observations” is made from an “Action Bar” and an “Observations Grid”. Notice how “Observations” and “Observation Grid” differ in their level of abstraction, this is important.

If you need to spark your imagination, I suggest you read this article from J.B. Rainsberger.

Rule #2: Do not assume your context

Thou shalt not care to know who thy DOM parent is

Do not assume your context

Now that you have components of decent sizes and with good names (don’t worry, this takes time to master), you might realize that there are far more opportunities for reusability than you ever envisioned. Read the remainder of this article to be ready for this!

DRY (don’t repeat yourself) is a good principle to adhere to, but components are not reusable by default; they must be made that way. The first thing you must be careful about is to make your components as context-agnostic as possible. After all, how reusable can a component be if it requires a specific context? Picture 40 components requiring 40 different contexts. Are you crying yet? If not, just know that in most cases, those contexts are neither obvious nor documented.

Do not worry, there is a simple way to prevent this! First of all, simply do not make use of your DOM parents or siblings! Imagine your components as having a “root” DOM node. You are not allowed to go upwards in the DOM past this point. Until web components are finalized and included in all major browsers, you may have to use discipline not to cross this boundary, but this can be done!

Now, this raises the question: how can we update a sibling or parent component? Think about it. It is OK for the parent to know about its immediate children, but a child should not know about its parent, yet it has to send a message to its parent. What pattern comes to mind?

There are a few acceptable solutions here, but one that is childishly easy to implement in JavaScript is an observer pattern. Call it observer or listener, for our purposes it serves the same goal: the child exposes a couple of listening points (say, onError, onNewDirective) and the parent registers a callback for it. Now you get components that do not need to know where they are included in the DOM or where in the DOM is the component they need to update. Awesome!

Rule #3: Give complete privacy to your children

Thou shalt not covet thy children’s DOM

Give complete privacy to your children

So far, we have named components that can be included anywhere in the DOM. Okily dokily! This is all fine and dandy, but chances are you will need components that are made from other lower level components (again, refer to atomic design for inspiration here!). That’s a good thing, but there is one strict rule: do not query your children’s DOM! I mean it. This is where most ripple effects start! You change one thing in that observations grid and somehow you end up breaking something else without noticing it. Or you do notice it and spend the next hour fixing all those places where they used that CSS class you just removed. Ouch!

This is fairly easy to avoid. However, as I said before, until web components are finalized, you may need to do this out of discipline. The reward you get in return is very high.

We now have clear boundaries for what a component can and cannot do. You are not allowed to explore the DOM upwards past your root node and you are not allowed to drill down in the DOM past your children’s root nodes.

This is nothing new. This is what encapsulation is all about! This concept has been around for as long as most of us can remember, yet we sometimes forget the consequences of not respecting encapsulation. Let the action toolbar know whether buttons are arranged with an <li> or a <div>. Instead, just call .addButton(myButton) on it. Do not interfere with the action toolbar’s affairs and let it handle its own buttons: it is its job! Now you have no reason to have duplicated jQuery selectors! All ripple effects from changing the DOM structure should now be contained within the boundaries of the component that manages it.

Oh, one last thing before one of you tries to hack this! Creating a method .getButtonElement() is not the way to go! Remember Tell, Don’t Ask? If you communicate with your parents using events, you communicate with your children using plain old message passing (i.e. method calls).

Rule #4: See the world from what you are given

Thou shalt assuage with what hast been given

See the world from what you are given

This is not a rule specific to UI components, but it is of crucial importance in JavaScript. Mainly this is aimed at all of you still using global variables everywhere, I hope you hit your toe on some piece of furniture!

You could state the rule this way: if a component requires a certain object to complete its work, it should be explicitly given to it. The only exception to this is if it is your responsibility to create said object. Since you have good names, it should now be obvious whether or not it is this component’s job to create the object. Just keep in mind that the factory pattern exists and is easily achieved in JavaScript.

Luckily, this is easily fixed in most codebases. Remember that your goal when refactoring is to work in small increments and keep the tests passing (you have tests, right?). If a component uses a global variable, just turn it into a method or constructor parameter instead. Then, whoever uses that component just passes in the global variable. Now fix those higher level components too. Rinse and repeat until you find the point of origin, then make an educated decision about where the object should reside.

This may seem complicated, but it is not. Now your components have explicit dependencies instead of requiring an implicit context. You improved the readability and reusability of your code, you should be proud! You will thank yourself in six months time.

As an added bonus, you just got rid of global variables which are a nightmare once you add concurrency. So far, JavaScript has been single threaded, but this will change. Better be ready than sorry!

What you should take home from all this

It sounds simple, doesn’t it? It should. Find good names, use events to decouple from your parents, delegate to your children and respect encapsulation, and make dependencies explicit. That’s it! This is not new nor ground breaking, but it should get you started on an happier path. Most of these principles are simply based on known best practices like SOLID principles or atomic design and none of this is web-specific. User interfaces have been around for ages and I think web developers should read more about the accumulated knowledge drawn from these years of experience.

The even better news is that it is fairly easy and fast to go from a humongous entangled to a structure of well defined and well behaved components. It is out of the scope of this article, but I might write about this at a later time. I will also show how to do it at my conference for Agile Québec on January 20th (in French). In the meantime, you can see a working example of this on my github repository. You will find 3 examples: one is a huge JavaScript file, one is a rewrite using React and the last one is a rewrite using only RequireJS.

Oh, also, here is one last bonus for you! You now have components that are trivial to test! Try it out, you might be amazed.

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.


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.


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.


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.


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.


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.


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


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+).