Vaadin Spreadsheet Webinar Wrap-Up

I hope you enjoyed our webinar about the Vaadin Spreadsheet. You can find all the source code and examples we showed during the session here.

You'll find the two following projects:

  • SpreadsheetDemo is the first example holding an empty spreadsheet - a minimalistic project sample.
  • spreadsheet-demo-repo is based on our speadsheet demo app in vaadin.com but holds all the example Excel files and has a simplified structure. 

Thank you for joining us and have fun with Vaadin Speadsheet! 

Jonatan

Stop wasting time on redeploys

A common question we get after our webinars or other live coding exercises is, how we make our live coding look so fluent. Why don’t you need to redeploy your war file to show the changes?

It is no stunt or a specially crafted marketing JVM – we're doing the real stuff. The “secret” is JRebel. JRebel is a commonly used tool among Java developer to speed up the development process by greatly improving the standard code “hot swap” features provided default by IDEs. 

Our friends at ZeroTurnaround just published a new 6.2 version, with features helping many Vaadin developers, so it is a perfect time to remind you how to become a more productive Java/Vaadin developer: Grab a free trial license and Install JRebel into your favorite IDE. That's it!

Improved GWT Support in JRebel

Many Vaadin users are at least some point involved with client side development with GWT. Typically when you are working with a fine-tuned custom component, you’ll build a custom client side counterpart for your server side API. With JRebel 6.2 you can skip redeploys in your client side code as well. JRebel supports both the traditional development mode and the newer “super-dev-mode” (that uses no browser plugins).

Many Vaadin add-ons depend on some third party JS libraries. In these cases it can be that the major part of your add-on code is about GWT-JS integration, typically written using JSNI. You can now add, remove and change JSNI methods with the same fluency that existing JRebel users have taken as granted with server side Vaadin code.

If you are writing pure client side applications or offline modes for Vaadin TouchKit apps, there are lots of other GWT related enhancements like support for GWT-RPC and AutoBeans. JRebel 6.2 also supports dynamic changes to CssResource interfaces (not just to the css file), that will dramatically speed up theme building for your TouchKit app.

What else is new in 6.2?

JRebel 6.2 not only includes the GWT and Vaadin improvements from above, but also includes better support for all of the flavors of TomEE.

Check out JRebel with Vaadin

Create UIs from data models using EMF

Are you sick of coding your UIs manually? Model them instead from a domain model to an application. One approach is model-driven development of user interfaces. With the Eclipse Modeling Framework (EMF) and EMF Forms, you can generate a domain model and a form based UI without manual coding. In this blogpost I'll give you a quick introduction on what the idea is.

Introduction to EMF

EMF is a pragmatic framework for modeling entity classes and generate code based on them. It all revolves around a Code generator for Java classes and it’s a standard framework for many model-related technologies.

The EMF Workflow looks as follows:

The main benefits of using EMF are:

 

  • No hand-written code
  • Model objects follow a common scheme
  • Model objects provide common functionality and API
  • Model can be validated before the code generation

 

Another advantage of Model Driven Development (MDD) is better code quality.

EMF provides Bi-Directional References and containment constraints. Additionally there are some validation constraints like Required Attributes, Lower Bound / Upper Bound and Custom validation rule. Furthermore, EMF provides a standardized API for Notifications for binding UI Elements, Reflection, to copy Elements, Serialization, to transfer Elements to a server and UI Support and to create Tree Views.

A small EMF Tutorial is available at the Eclipsesource blog.

Introduction to EMF Client Platform (ECP)

ECP is a framework for supporting the development of applications based on EMF entity instances. The UIs are described in a separate model (view model) and are not developed in source code. The view model contains all layout and controls, like fields, vertical layout, group etc. This view model is independent of a concrete UI Toolkit so you could use Eclipse RCP/RAP or even JavaFX. In this blogpost I will show you how to use Vaadin for the UI.

The benefits of ECP are the following:
  • Extensibility and Adaptability, you can create custom controls
  • UI Model is independent of renderer technology
  • less handwritten code
  • JFace Databinding for Vaadin
  • Modularity with OSGi
  • CRUD UI

In the next steps, we want to create a UI for the user entity.

The view model describes a view with 2 columns.

The Vaadin view looks like this:

The Code for this UI is just:
VaadinObservables.activateRealm(ui); 
ECPVaadinView ecpVaadinView = ECPVaadinViewRenderer.INSTANCE.render(USER); 
setContent(ecpVaadinView.getComponent());

Every element can be customized such as for instance the email element. We want to send an E-Mail after submit.

There are no surprises or magic. The Code is:

final Component textComponent = super.createControl(); 
textComponent.setWidth(100f, Unit.PERCENTAGE); 
final Button button = new Button("Send Mail"); 
final HorizontalLayout horizontalLayout = new HorizontalLayout(textComponent, button);

For more information, there is a tutorial available at the EMF blog. The tutorial contains the described example to test and play around with.

Conclusion and resources

The conclusion is you can create a UI much easier and faster, when you describe it.
You reduce errors because reoccurring problems like data binding are no longer done manually. I've collected some pointers on when you should and shouldn't consider using modeling below.

When to use UI Modeling:

  • Large Domain Model with a huge amount of input fields
  • Form based Views
  • Frequent Domain Model changes
  • Homogenous UI
  • UI Technology Independence
  • Improved Customer Involvement
  • Fast Turnaround + Rapid Prototyping

 

When not to use UI Modeling:

  • pixel perfect UI
  • Many Actions and Buttons in the UI

 

Please also note that this isn't a full Application. For a full application you need more around the generated views such as implement navigation, persistence and so on. The first company that created an application with the Vaadin renderer is Compart AG.
The Vaadin Renderer is open source and available in Github.

Currently the renderer's registration is done within Equinox (OSGi) to build dynamic web apps. The approach can be adapted to a non-OSGi environment by manually doing this registration with a Map. For comments and questions please leave a comment below.