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”
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.
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!
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 –
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.”
We are pleased to announce that we are going to hold our live Q&A with Francesca Tosi and Alberto Mancini on October 28th.
Francesca and Alberto are both the organizers of the GWTcon. This Q&A is a great opportunity to learn more about GWTcon, the event and why they are doing it.
GWTcon is a community-driven event which tries to involve the community around the GWT Toolkit as much as possible.
GWT being an open source project, we think it really needs and requires an healthy community of active developers and users that are willing to share experiences, opinions and real word practices.
- Francesca Tosi is a Freelance, web & mobile Developer and Architect, with a passion for fine tuned details. Co-founder at JooinK (www.jooink.com). GDG-Firenze Lead and founder. Intel Software Innovator. GWTcon organizer.
- Alberto Mancini is a passionate (web & mobile) developer and linux sysadmin. Co-founder of GDG-Firenze and GWTcon organizer. He loves to learn new programming techniques and to demonstrate how modern browsers can do high performance computations, of course using GWT.
We are pleased to announce that we are going to hold our first live Q&A with Maxime Meriouma-Caron and Olivier Lafleur on October 7th.
Maxime and Olivier are both Arcbees’ employees who worked on the new release. This Q&A is a great opportunity to learn more about GWTChosen, or offer suggestions about how it can be improved for future releases.
You’ll also gain some insight into how we work at Arcbees, and get to know two of the Bees who contribute to and help support our open source projects.
- Olivier is an Open Source and Open Web enthusiast. As our “community gardener”, he likes helping new Bees explore the Arcbees ecosystem, and really spread their wings.
- Maxime is a passionate developer always up for new challenges who joined Arcbees in 2011. Over the past several years, he has contributed to GWTP and other open-source projects, including GWT-Chosen, Jukito, GWT-Query plugins, TeamCity plugins and GWT-SEO. He has also acquired significant expertise in the Google Cloud Platform, in his role as lead developer on many projects.
Erratum on the event date: It will be held on October the 7th with Maxime and Olivier from Arcbees on this release
We’re happy to announce the latest major update of GWTChosen – version 3.0.
This release includes a mobile version of GWTChosen. The full release notes on GitHub describe it in detail. The whole purpose of GWTChosen has been to make long, unwieldy select boxes user-friendly. However, the mobile experience still wasn’t smooth enough, so we refactored the code. Now mobile users can enjoy the same ease of use that GWTChosen gave people on larger screens.
If we compare the desktop and the mobile version of Chosen, we see that each one is a good fit for its context of use.
Single Chosen on desktop :
Single Chosen on mobile
Multiple Chosen on desktop
Multiple Chosen on mobile
If you’re not sure how to include GWTChosen in your project, check out the documentation. We made it as easy to include as we possibly could (hint : it’s a one-liner ;-)).
As Philippe said in his last blog post, we will start a series of Q&A sessions with leading lights in the GWT Universe. First up will be on the release of GWT Chosen. It will be held next week for a live Q&A on October 7th! You can already register for the event here.
Subscribe to our newsletter to receive more articles of this type in your inbox. Stay tuned for a follow-up article on how to use the GWTChosen custom styling properties.
Last week, we organized our first hackathon ever. It was two days of real fun, focusing on the core of our business : our open source projects.
To help make it even more fun, we assigned team different colors. Each one could win points and leaders could “punish” other teams (mostly making bottom teams serve Mr. Freezes and beer to the other teams ;-)).
The two main focus of the developers were to release the 1.5 version of GWTP (which has been in the making for a few weeks) and to solidify and update the IntelliJ plugin.
Mission Accomplished! It’s time to unveil the latest creations from our team at Arcbees and our many external contributors.
One feature of this release is simplified boilerplate for nested presenters. We don’t need the @ContentSlot annotation anymore. It is now replaced by a NestedSlot type. The @ContentSlot still works but is now deprecated. You can read more about this new slot mechanism on our developer portal.
We also added name token configuration to the DefaultModule builder. As always, we also improved our Rest-Dispatch to be even more useful to our users.
For those of you that were using the IntelliJ plugin, there was a nasty bug that prevented the user from creating a project with the newest archetype and the newest version of IntelliJ. So, it was the first thing we worked on during the first day of the hackathon.
Next, we improved the user experience of the Create Presenter dialog to make it simpler and to make it more clear to describe what is going on.
You can download the last version on the JetBrains plugin repository.
Also, if you prefer to use Maven alone, we just released a short video on how to start a new GWTP project (french version here). Fundamentally, it is the same process the plugin uses when creating a new project : executing the Maven instruction to generate the archetype from a Sonatype repository.
As you can see, the goal of this release is to simplify your GWTP experience as much as possible.
Thanks for your invaluable feedback. It helps us create products that are relevant in real use cases and that immensely simplify a developer’s daily work.
If you’re curious about where we are going with the next major version of GWTP, you can watch this presentation that Christian Goudreau gave at the last GWT.create. He was talking about how to improve your productivity with GWTP, but he gives a glimpse at the end of the talk about what lies ahead for GWTP.
Stay tuned for more to come and feel free to let me know how we can help you become more efficient with this framework.
When looking for a framework to build our codebase on, we came across GWT. Although we didn’t have any prior experience with GWT, we were a team of seasoned Java devs, so it seemed a natural fit for our skillset. Plus it offered the client-side UI building approach we still believed in. Still, a lot of base work was required to build out the basic infrastructure of our application. This is where the GWTP framework came in handy. It made our introduction to GWT much easier and gave us a headstart in development.
One of the major problems of our vanilla JS solution was that we had to take care of every single piece of application and UI logic ourselves. And, because Ruxit is a single-page application, there was a lot of logic to be tracked. GWTP provides lots of helpful boilerplate functionality like view lifecycles and connecting URLs to corresponding views. GWT is a great technology with a learning curve that’s not too steep. However it does take some time to adjust your mindset to the work approach that’s required for succeeding with GWTP.
As mentioned, GWTP made our start with GWT much easier but at the same time the framework it provides is not restrictive. Yet it covers most of the basics that are needed to successfully get your application up and running. Over the time that we’ve worked with GWTP—which is three years at this point—we’ve never felt that GWTP has constrained us, which is phenomenal. We’re convinced that it’s the balance between structure and freedom that makes GWTP so appealing.
One of our favorite features in GWTP is code-splitting. Sure, code-splitting is included with GWT, but you have to take special care to set the split points right. If you don’t get the split-points right from the beginning, it can be really hard (if not impossible) to introduce them later as the code is usually too tightly bound by then. GWTP’s Model-View-Presenter architecture offers an easy and efficient solution to this problem. By applying MVP, your code automatically comes in the right granularity for code-splitting. Without it, we would likely be in a very bad situation at this point, needing tens of megabytes of UI code to be loaded into the browser right from the start. Instead, when opening a Ruxit view for the first time, only the code required to render the current view is downloaded.
With GWTP your code is typically loosely coupled. The advantage to this becomes apparent once your team and code grow in size. Today we’re about three years into development with GWTP and we’ve grown into six teams spread across three countries with almost 230,000 lines of code checked into our repository. Thanks to GWTP our teams don’t step on each other’s toes; each team only runs the views that are relevant to their work. This makes GWT development much faster and less error-prone.
As we had a considerable amount of backend code running from the vanilla JS version we developed early on, we didn’t want to revise all of it just to match our new GWT frontend. That’s why we decided to stay with JSON for communication between our frontend and backend. With this approach, we were able to re-use nearly 100% of our backend functionality without losing anything. The web really is a great place to be a dev. 🙂
We believe that seeing is believing. So, want to see what can be achieved with GWT and GWTP? Have a look at the screenshots of Ruxit below, or better yet, sign up for a free trial of Ruxit.
We’re very proud of our results with GWTP. Having started several additional projects since then, no one was looking for a new development alternative when a new project came around.
Subscribe to our newsletter to be notified when the next post comes out!
Through experience, I have come to realize that writing Google Web Toolkit Generators is far from being easy. In fact, when it comes time to improve the existing code base or add features, it turns into a nightmare. I’ve found all sorts of GWT Generators. Some were easier to understand than others, but every single time, it took me hours before I could do anything useful. That made me wonder, how can we improve the readability and the maintainability of a piece of infrastructure that inherently is hard to maintain due to its design?
- The answer
- Example: Cell Table
- The code generator
- What’s next?
The answer was quite simple. We actually see the solution pattern all around us in one form or another. It’s templates. I first thought I’d create my own template engine optimized for GWT, but then I came across Harald Pelh’s Piriti project and saw that he was already using the Velocity template engine for this purpose. My team is already using Velocity for other reasons, and I was stunned that I hadn’t considered using it for GWT Generator templates myself. Good on ya’, Harald!
Example: Cell Table
To introduce you to Velocity and demonstrate how I write code generators, I’ll go through a simple case that everyone has experienced in GWT: column definition in cell table widgets. They are redundant, tedious to write, and could be simplified by the smart application of abstraction and code generation. First let’s review how a simple table is written:
Extracting the column definition
It is clear to see how a bit of abstraction would let us extract the column definition. We will extract the column creation logic to its own interface and class. Looking more closely at the view, it’s also clear that it is burdened with too many responsibilities. Delegating the column creation logic to another object is a lot more elegant and better respects the Single Responsibility Principle.
Now that we extracted around 40 lines of code from the view to its own class, let’s use this class in our view:
Extraction of the creation logic to another class tidies up the view a lot. This is the key to my procedure: FIRST write real use cases before attempting to write ANY code generators. If you don’t, you will fail to truly understand your problem and will end up overengineering the solution. I’ve seen that countless times through the years. Even experienced developers skip the mandatory step of writing several use cases before implementing their code generators. It may seem redundant, but its not. It’s iterative, and clarity grows as your iterate. You first start by just writing out the case, then write it a second time, and abstract it. Write it a third time, abstract again, simplify; and only then should you write the generator, based on the actual use cases you’ve developed, which after several iterations is now at its most simple expression.
Transforming the column definition
With a real use case to guide us, let’s transform our column definition as an interface:
There are far fewer lines of code now! And the beauty is, if I want to remove or add a column, I only have to alter a single line! Does this remind you something? Bingo! This is exactly how Proxies with request factories are written! That being said, that also means that some rules need to be followed. Each method name has to match the method name in the POJO We could change this by adding an annotation argument, but this class already isn’t refactor-friendly, and an annotation argument would make that worse, so let’s keep it simple. Going even further, the interface could refer to a template like UiRenderer, ui.xml and be generated using the XML definition instead! Let’s keep that as food for thought.
The code generator
From this interface, you can now create your code generator. Since I know what the output will be because I have already written a working column definition class, I’ll use this code inside a Velocity template:
Before going further, I need to wire up all the needed classes for my generator. I find that using Google Guice really helps in creating classes that are simple, yet uncoupled, which leads to better readability as each class only has one responsibility. Now the fun begins, as we add the glue that GWT will use to transform this Velocity template into java.
This generator serve as my entry point for instantiating my Velocity Generator through Guice. Its only purpose is to set up the context and kick off generation. Nothing else. When it kicks off the generation, the generator will use the Velocity generator to start the code generation process:
It is really straightforward, I populate the ColumnsInitializerDefinitions class with all the information I need and that will be used inside the Velocity template. Then I give it as an additional argument in the Velocity context map. I’ve also made an abstraction of this Velocity setup that I use all across my projects to avoid repeating myself over and over.
This process may be a bit counterintuitive because to create generators that are easy to maintain and read, while being flexible enough to evolve, you need to repeat yourself! But consider this – in software engineering, when does it make sense to repeat yourself? When instantiating Design Patterns!
Design Patterns are architectural motifs that are repeated over and over with different parameters, to fit the specific requirements of your system. Some good candidates for code generation are Business Design Patterns, that resolve recurring system requirements in your application context.
You don’t have to be Martin Fowler or the Gang of Four to invent design patterns. Building software architecture for a specific business will require you to think out of the box about patterns that may not exist, but solve recurring problems in the context of your system.
Now we only need to wire the generator to the interface that needs to be generated:
First, we could add a lot of functionality for sorting, action cells, editable cells, and the like. I have only scratched the surface above, but even so, we can already see a big gain in productivity. Furthermore, we could use annotation processors instead of GWT Code Generators! While GWT gives a lot of goodies, we can’t really use those generators with anything else but GWT. Using annotation processors or any other java code generator framework, we can build code generators that are portable and, with a little bit of what I shared with you, maintainable.
If you’re looking for the sources and some of the missing classes, I invite you to take a look at the GWTP-CarStore sample. Have fun! 😀