Close

Community Spotlight - August 2016

Welcome to another edition of Vaadin Community Spotlight. This month I had the opportunity to talk to Benjamin Larsen. Benjamin is a Software Developer who works for TDC, a big telecommunications company in Denmark, and he has been using Vaadin recently to develop an interesting web application. The most interesting part of his story is that he didn’t have much experience with web development or Java but still managed to deliver a completely functional web application on time.

Hello Benjamin, great to talk to you! Have you ever been to Finland, BTW?

Hi! I would love to visit Finland some time. All that forest and all the lakes, would be awesome to fly in!

It's pretty nice yeah, but I've heard Denmark is awesome as well! So... you are currently studying there, right?

That is correct. I'm studying at Aarhus University to become an ICT-Engineer, Information and Communication Technology. Just started my 6th out of 7 semesters and I also work as an Engineer Trainee for TDC Group. I’ve been working here since 2014, when I started in our technical support.

Cool! Do you find it challenging or difficult to study and work at the same time?

Yes! It can be a pain in the back. But as long as my work is okay with me putting school first, then it's all good. Especially when you love your job so much that you don't even think of it as a job. Seriously, sometimes I ask myself, "are they paying me for this?".

I’ve been there so I totally understand! How did you learn how to program?

Well. I had a small web design company back when I was in high school. That gave me the basic knowledge of programming. But it was when I took a basic course as an electrician that I fell in love with programming. Though it was with relays and electronics, I loved how AND/OR/NOR/NAND could drive an engine, or change a light setting. Later, when I began studying at Uni, I learned C, then C++ and then C#. So real programming was through my education.

How about Java? How did you jump into it?

Well, it's not that much different to C#, you know. So it wasn't really a big problem. I think the hardest thing (compared to what we did in school) was to make it all work in a new IDE, with an Application Server and so on. I needed something that could run on Linux, without me needing to do anything special, and it also should be “high level”. So Java was the obvious choice. I never developed a web application before I met Vaadin. I did use WPF in C# to build GUI's, though.

Interesting! How was it? Why Vaadin? How did you discover it?

Well, I wrote a backend for the system, and then decided to look for frameworks. I looked at many discussions and talked to some friends, and so on. Then I looked at two frameworks, Grails and Vaadin. My friends used Grails, and they all looked so depressed, haha! So, I just looked at some discussions about Vaadin and it seemed like a good, well documented framework with a great community. And it reminded me a little bit about WPF. I started the project in February and finished in late June. Though I am still maintaining it, of course.

I had a look at the screenshots, nice job! I mean, you did all that without any previous experience with Java and web development, right?

Correct. That just shows how easy it is to use Vaadin. Seriously. Look at some tutorials, and play. I've never experienced a framework that is so easy to get started with. The Vaadin community is awesome, the documentation contains examples, and it just works. No need to do all kinds of setups.

That's good to hear! So, what’s the application you developed all about?

The application simply creates a way to set up tests of DSL equipment. For example, when a new internet router comes up and a company wants to use it on TDC lines, we'll test it for them. The way we do it, is by creating a test (through the software) which iterates over a different set of lengths. For example from 0-2500 meters, and then logs data from the DSLAM (the DSLAM is the other end of a DSL line) and the router. Sometime it might show that at 1450 meters, the router does something weird, which needs to be fixed. Though it can test much more.

But the real fun stuff came when I needed to get the frontend to grab and show data from the DSLAM's. Again, with Vaadin it was super easy. In the end it was awesome to see users just choosing a couple of profiles, and then the system created everything automatically.

Interesting project. So it sounds like the final users were happy with the application you developed, right?

They really liked it. Before, they had to set up XML-test-scripts, where they manually have to type everything, and hope they didn't make any mistakes. They got their results as XML-files as well, so it wasn't really user friendly, and was really outdated. I received only good feedback, so good that it wasn't a problem buying Vaadin Pro Tools in case we need to make new projects.

So, what would you say to those considering Vaadin as an alternative to, say, C# or to those without too much experience with Java and web development?

Try it! It is so easy to start working with Vaadin, and it's so easy to maintain. For a noob-webapp-developer like I was, Vaadin is perfect. You can create a small project, and then get a feel for it. Then simply just continue to play with it. And get in the community, you might not know what to do, but someone in the community sure does!

And I have a great example of this: https://vaadin.com/forum#!/thread/12987749
This dude created an example project, just to teach me how to do it. HOW AWESOME IS THAT? That's Vaadin community for you!

Nice! And it was super-nice talking to you, Benjamin. Thanks for your time and best wishes in all the upcoming projects.

Right back at you!

Vaadin Framework 7.7 is out

On behalf of the Vaadin team, I am pleased to announce a new release, Vaadin Framework 7.7.0. The release contains major improvements for widgetset handling and a bunch of bug fixes.

Much less GWT (compiling)

By default the concept of widgetset is now completely hidden and you don’t need to think about it anymore. The GWT module definition file, the one that ends with *.gwt.xml, is now by default a generated resource and should not be added to source control management systems like Git. If a developer doesn’t have any (client side) add-ons in the project, the default widgetset is used and the build is super fast. Client side add-ons added to the project are automatically detected by the build script and a generated widgetset is compiled during a normal build. So no more hassles with .gwt.xml files or @Widgetset annotations, unless you explicitly define those for advanced use cases.

The most interesting improvement, however, is that you don’t need to spend your precious CPU time to do the widgetset compilation anymore. If your project is only using publicly available add-ons, you can use a new cloud service that will compile the widgetset for you. And we’ll store each permutation of framework and add-on combinations, meaning that if somebody has ever requested the same widgetset before, you’ll get it immediately without waiting for the longish GWT compilation at all.

A third enhancement to the widgetset handling is that the cloud service can also host the compiled widgetset. This makes your war files smaller and can also speed up the launch time of your application as its resources are loaded from multiple domains. The Vaadin CDN service is geographically distributed – thus reducing the latency. Still, in production applications, we suggest to serve the whole application yourself.

A more thorough explanation can be found from a recent blog entry, but we are also hosting a webinar explaining the widgetset changes next week, sign-up for that now!

LoginForm de-deprecated

The LoginForm was deprecated a while ago, when modern browsers stopped autocompleting usernames and passwords to it. Luckily an avid community member, Ingo Kegel, found workarounds for this issue and created a LoginForm add-on that works across all modern browsers and became immensely popular.

Ingo contributed these changes to the core and the new version of the LoginForm component is heavily based on the work done in his add-on. There are some small API changes and incompatibilities with the deprecated version in Vaadin 7.X, but it now works with all modern browsers and the @Deprecated annotation is gone. Also the login form can now be customized in plain Java as opposed to the previous HTML template solution.

Build the framework yourself!

There are also some changes under the hood. Vaadin Framework is now built using Maven and the build can be really easily repeated by anyone. This makes it more agile to work with the Vaadin Framework project itself and we hope it will make it much simpler to contribute to the core framework. This is how you build your own custom version from the master branch:

  1. Checkout the project (git clone …)

  2. Make your desired changes

  3. Build a snapshot version (mvn install -DskipTests)

  4. Change your project to use your snapshot build

The long list of smaller bug fixes and enhancements can be read from the release notes.

Get 7.7 now

Simplifying Multiplicities for Agile MVP

It’s 2016 and guess who just turned 20 years old? Extreme Programming! You might not have thought it was around that long but Ron Jeffries in his “XP at 20” webpages assures us we can start counting from the year 1996. You might remember the first book on XP was published in October 1999, but Kent Beck was actually putting the ideas behind XP into practice three years before that.

2016 – 1999 + 3 = 20. So XP is 20.

In this article we will focus on one of the four values of Extreme Programming, namely simplicity. We’ll explore how far we can stretch that concept and try to apply it to one of the more recent UI design patterns, the Model-View-Presenter.

Nothing like the present

One of the thrusts of XP has always been simplicity. XP’s particular brand of simplicity is supported by the observation that developers are about as lousy at anticipating future user requirements as users are at describing their current ones. Therefore, the well-meaning attempts of developers to speculatively build features today in the hope of minimizing their context switching tomorrow, wind up costing them more time than they save. The advice from XP is to pursue simplicity through restraint – write software to the current needs of the users only, and avoid developing features that aren’t explicitly required now.

As the popularity of the simplicity value of XP has grown, the aphorism “You Ain’t Gonna Need It” or YAGNI has emerged to reinforce it. As a motto, YAGNI can stretch the simplicity objective beyond the classic forward-engineering scenario to the refactoring of existing software. The idea of “not required now” includes features that may be needed in the future (“not yet required”) but also those that had been at one time in the past (“no longer required”). YAGNI also applies to design so we ensure it also is a fit for the required features: we avoid overengineering and don’t add or keep layers of abstraction that aren’t necessary.

In object-oriented languages, this striving for simplification is a good counterbalance for patterns. Patterns enable us to develop infinitely complex technical classes and give them the illusion of meaningful purpose using a standardized domain-neutral naming. Two developers with a good understanding of patterns could both be tasked to write an ObserverVisitorFactoryFactorySingleton and both will probably write very similar code. This code can be written, moreover, without having to answer the question if such an over-engineered construct is actually needed. YAGNI has a neat role to play.

Simplifying features to patterns

If we can use YAGNI during refactoring to simplify designs so they support only the required features, is there also an opportunity to simplify our patterns to support only those features used by our designs?

Let’s take MVP. To recap briefly, MVP improves the older MVC UI pattern by dumbing down the view’s responsibilities to layout and event handling. The benefit is the separation of UI framework APIs from the presentation logic, which leads to:

  • Understandability of the operations of the interface in business-oriented terms (like “add customer”) in addition to the events of the interface in API terms (like “OnClick”);
  • Improved testability of the presentation logic;
  • Presenter’s indirect dependency on the view implementation and, by extension, the UI framework involved.

The standard template for MVP allows us to reap all of these benefits also in Vaadin applications. If we choose the right names for the presenter methods, remove from our views as much logic as we can, keep the presenter clean of dependencies on items from the com.vaadin.ui package, and let the presenters push updates to view implementations through references typed as interfaces, these benefits can be realized. The problem we’re left with is that MVP takes a lot of work and discipline, both when developing systems anew and when refactoring. For applications containing many screens for which users have rapidly changing requirements, the extra work might make it hard to justify the investment.

But can YAGNI help us here? Can we identify parts of the pattern that we do not need in order to fit our requirements of understandability, testability, and indirect dependencies? One place we recently considered with a Vaadin customer was the area of multiplicities.

E pluribus

A part of the complexity of MVP is its support for many 1:n multiplicities. Obvious examples would be being able to place hundreds of components on one view layout, or to add hundreds of listeners to one single event. There are two cases in which the actual needs of many enterprise UIs do not exceed 1:1 multiplicity where MVP allows 1:n at the cost of increased complexity: the number of views per presenter and the number of population types per view.

The first category is the easiest to understand and implement. Instead of working with an observer-type “add listener” pattern to associate our presenter with n views, we can simplify with a setter if there is only one. With DI, the view will get its presenter autowired and then invoke something using “this” to make the presenter aware of the view(s) it needs to populate.

One example:

package com.generalbakeries.erp;

import ...;

abstract public class GeneralBakeriesPresenter
{
  GeneralBakeriesDisplayable view = null;

  public void setView(GeneralBakeriesDisplayable val) {
    view = val;
  }

  abstract public void populate();
}
package com.generalbakeries.erp;

import ...;

@UIScope
@Controller
public class EmployeeListPresenter
       extends GeneralBakeriesPresenter {

  @Override
  public void populate() {
    view.display(EmployeeService.getEmployees());
  }
}
package com.generalbakeries.erp;

import ...;

@UIScope
@SpringView(name = ...)
public class EmployeeListView 
       extends GeneralBakeriesView
       implements GeneralBakeriesDisplayable {

  @Autowired
  EmployeeListPresenter presenter;

  @PostConstruct
  public void init() {
    this.addComponents(...);
    presenter.setView(this);
  }

  @Override
  public void enter(ViewChangeListener.ViewChangeEvent vce) {
    presenter.populate();
  }

  @Override
  public void display(Employees emp) {
    this.setContainerDataSource(cont);
  }

}

The second is more nuanced and considers the asymmetry between the number of types of event data that originate in the interface and the number that originate in the server. Even simple views will support multiple components and will generate multiple events that need to be forwarded to the presenter. Simple views in business applications, on the other hand, can often be populated in one single way.

In MVP the mechanism we’re given to populate the view implementation is the view interface on which we can define as many methods as we want. If are able to simplify and reduce the number of methods to 1, then we actually no longer have a requirement to define a view-specific implementation and interface for each view. Instead, we can use one shared view interface containing one method with a parameterized type argument. Such a base interface could be simplified to the following:

package com.generalbakeries.erp;

public interface GeneralBakeriesDisplayable<T> {
  void display(T dType);
}

If our UI contains a header, sidebar, footer, and a body, and the body is the container for our view navigation, and if our views are simple, a large portion of our UI could be composed of implementations of this interface. The samples below show how this would look for a view that shows a list of employee data and one that shows a single employee detail. Differences between the two are highlighted in bold:

package com.generalbakeries.erp;

import ...;

@UIScope
@SpringView(name = ...)
public class EmployeeListView
       extends GeneralBakeriesView
       implements GeneralBakeriesDisplayable<Employee[]> {

  @Autowired
  EmployeeListPresenter presenter;

  @PostConstruct
  public void init() {
    this.addComponents(...);
    presenter.setView(this);
  }

  @Override
  public void enter(ViewChangeListener.ViewChangeEvent vce) {
    presenter.populate();
  }

  @Override
  public void display(Employee[] emp) {
    ...
  }

}
package com.generalbakeries.erp;

import ...;

@UIScope
@SpringView(name = ...)
public class EmployeeDetailView 
       extends GeneralBakeriesView
       implements GeneralBakeriesDisplayable<Employee> {

  @Autowired
  EmployeeDetailPresenter presenter;

  @PostConstruct
  public void init() {
    this.addComponents(...);
    presenter.setView(this);
  }

  @Override
  public void enter(ViewChangeListener.ViewChangeEvent vce) {
    presenter.populate();
  }

  @Override
  public void display(Employee emp) {
    ...
  }

}

The presenters would look as follows:


package com.generalbakeries.erp;

import ...;

@UIScope
@Controller
public class EmployeeListPresenter 
       extends GeneralBakeriesPresenter {

  @Override
  public void populate() {
    view.<Employee[]>display(EmployeeService.getEmployees());
  }

}

package com.generalbakeries.erp;

import ...;

@UIScope
@Controller
public class EmployeeDetailPresenter
       extends GeneralBakeriesPresenter {

  @Override
  public void populate() {
    view.<Employee>display(EmployeeService.getEmployee(..));
  }

}

The knowledge whether a view has a single or multi-method interface will often only be needed by the presenter, so complexity can be added or removed as needed without impacting the other parts of the system. And if views start out simple, the single-method implementation will actually reinforce simplistic thinking.

By simplifying the patterns wherever possible so to minimize the number of classes and also providing support for views to be addressable indirectly through single-method interfaces, we are implementing and encouraging the fourth rule of XP Simple Design. This rule is to minimize the number of classes and methods. By following this rule we expect to achieve more agility and better quality software.