Vaadin

We're pleased to announce the public release of Tori – the modern and sleek discussion forum for Liferay portal. We've kept Tori under the blanket while developing it and gathering feedback from you in the Vaadin community for more than a year, but now the time has finally come to turn on the spotlights and direct them at Tori.

Did you think you knew Tori? Look again. It's completely renewed since 4 months ago, with a new look and feel and many smaller enhancements since then.

What then makes Tori special? Isn't there a Message Board inside Liferay already by default?

Tori is a full-blown single page application where you move smoothly between threads and topics. Another central part of Tori is push messages. Whenever somebody posts a message or is writing something in the same thread as you (psst! did you notice the rich text in-place editing of your posts?), you'll immediately see what's going on in real-time.

The largest enhancement in the latest release, Tori 1.1, however, is continuing the beautiful UI experience to your mailbox. And being a generic portlet, all this is tweakable in the admin console of Tori, so that you can make it look just like your own portal. And even more enhancements based on your feedback are in queue.

The theme in Tori is customizable with Sass (or CSS) to fit your look and feel. You'll be able to make it look like your own site, online as well as in the emails. But we didn’t stop there. You can also create your own custom tags. We've even started hosting our Webinars inside Tori through a custom youtube-tag.

We've also built in SEO support so that search engines crawling the site can crawl for all the relevant data while at the same time maintaining full backwards compatibility with Liferay's own message board. And you can add Google Analytics by just adding your UA-code to the settings screen. Tori is a full drop-in-replacement for Liferay Message Board that follows your message board settings and privileges plus so much more.

Tori, meaning 'town square' in Finnish, is available through Liferay Marketplace as a free download. You can also get it as source code directly from GitHub.

Tori will work inside any Liferay instance starting from version 6.0 and you can even run it simultaneously with the native Liferay Message Board. There’s no reason why you shouldn’t use it today.

Get Tori from Liferay Marketplace

Fredrik Rönnlund has been working at Vaadin Ltd since 2008. Today he works as the Batman of Vaadin Marketing, helping create meaningful content to the Vaadin users by day and fighting evil bugs by night. You can follow him on Twitter – @freducom

There is a point in every enterprise web application project when the scalability of the application under development is wanted to be measured. There are several reasons for why scalability tests are done. To begin with, there is a need to see how the application will perform on production like environment. Then, the peak performance or breaking point of the application is wanted to be found out. Finally, scalability tests can be utilized to find performance bottlenecks, bugs and memory leaks.

We in Vaadin take scalability seriously. That is why we built a full stack application called QuickTickets a couple of years ago. QuickTickets has been our platform for scalability studies. If scalability is of any kind of interest to you, you should check out the Vaadin Scalability Study blog post which is still valid today. 

Apache JMeter has most often been the de facto tool for scalability studies. Apache JMeter is an open source desktop application designed for Web Application performance testing. JMeter does not render the UI in a browser like Vaadin TestBech and Selenium do, but instead it has the ability to simulate and gauge a server load of hundreds and thousands of concurrent web users. This functionality is achieved by recording the client to server requests of the Web Application which is then played back by several numbers of concurrent threads.

QuickTickets is based on Vaadin 6; so are there any changes in Vaadin 7 that the scalability tester should be aware of? Yes, there is, at least one. In Vaadin 6 you could set component ids used in the client-server communication using the setDebugId() method. By default, a Vaadin application sets a sequential id for each component of the application. This id sequence is likely the same between different runs of the application, but this is not guaranteed. By setting the component id by hand, it helps you to keep your test valid even when your Vaadin UI is changing during the application development.

In Vaadin 7 the setDebugId functionality has been removed, since it might cause problems if the ids set by the user are not unique. In order to make your scalability testing as smooth as possible, I've prepared a tutorial that oulines the measures you need to take to test your Vaadin application. Please, take a look at the step-by-step tutorial of testing Vaadin 7 applications with JMeter. It covers JMeter testing of both Vaadin 6 and Vaadin 7 applications. And as always, if you have any comments or questions, post them here and I'll get back to you.

Read more in the wiki

Johannes Tuikkala works as a Vaadin Expert who has been working in different customer projects for 6 years. He likes to do photography and winter swimming on his free time. You can reach him by email: johannes@vaadin.com.

Vaadin TestBench is a browser automation tool, suited for creating UI level tests for Vaadin applications. It is based on Selenium 2, which means that all features of Selenium 2/WebDriver are also available in TestBench. But what exactly does Selenium 2 / WebDriver do? And how does Vaadin TestBench work?

Like many of you might know, Selenium has been around for quite some time. Started in 2004, the first version was solely JavaScript based. It was a small JavaScript application running in the browser, commanding the application to be tested.

WebDriver takes a different approach to solve the same problem. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser and to bypass the restrictions placed on the browser by the JavaScript security model. This allows Vaadin TestBench to use a cleaner, object-based API, rather than follow the original dictionary-based API. This is also what Vaadin TestBench uses:

 // Create an instance of Firefox
setDriver(new FirefoxDriver());

// Now go to the Vaadin home page
getDriver().get("https://vaadin.com/home");

// Find the search input and run a search
WebElement siteSearch = driver.findElement(By.id("query"));
siteSearch.sendKeys("vaadin charts");
siteSearch.submit();

In TestBench 4 Selenium’s object-oriented API has been taken even further. The Vaadin element query API helps Vaadin developers find Vaadin components and access their properties in the browser. These component properties include caption, description, child components, cells in tables – as well as Vaadin specific actions like closing notifications. The Element APIs in the com.vaadin.testbench.element package extend the org.openqa.selenium.WebElement which makes them fully compatible with Selenium.

With Vaadin TestBench the components are queried like this:

 List<ButtonElement> buttons = $(ButtonElement.class).all();

Here the ButtonElement class is a specialized WebElement, which contains API for interacting with Vaadin Button components. There are Element class counterparts for all the core Vaadin components in Vaadin TestBench and add-ons can introduce their own when needed.

You can use several different ways to locate and interact with the UI component elements.

The most robust way is to use component identifiers. To use these, you first need to set unique identifiers for your components in the application code. A save button in a form could, e.g. use btnSave.setId(“form-save”). In the test code you can then click the actual element by calling:

 $(ButtonElement.class).id("form-save").click();

When IDs are not available, you can use the caption to find a Vaadin component in your application. Often enough the caption is a unique enough identifier for your component, as you rarely have too many components of the same type with the same caption.

 $(ButtonElement.class).caption("Save").first().click();

ElementQueries also allow you to define a search hierarchy, which means that you can easily search components within components.

 $(PanelElement.class).caption("Form").$(ButtonElement.class)
                .caption("Save").first().click();

Of course you can do most of the same things with XPath using Selenium’s rather complex but powerful syntax. Vaadin TestBench 4 is fully compatible with your existing test cases and will stay that way.

This was a glimpse into the upcoming Vaadin TestBench 4. Check out the examples in GitHub, but if you want to use Vaadin Testbench now, Vaadin TestBench 3 is fully forward compatible (also license-wise) and a safe way to start automating your browser testing today.

Jonatan Kronqvist is a Senior Vaadin Expert leading a team of awesome developers building the next versions of Vaadin, TestBench and other tools that streamline the development process and help our customers build the best UIs in the world.

Servlet 3.0 is awesome, so is CDI. They work well and are a joy to set up. Even adding the Vaadin Navigator to the mix isn’t an issue, since you can use the CDIViewProvider to maintain the injection chains. Everything works nicely with annotations, and you don’t need to mess around with nasty XML. But what if you want to use JAAS? Recently, I stumbled upon a small dilemma in a customer project where the customer wanted to use JAAS in combination with CDI. How in the world was I going to combine the two?

To get us all to the same page before we start; here is a very short introduction to JAAS. JAAS, or the Java Authentication and Authorization Service, has been around for a while. It is an API for Java to manage user authentication and request authorization, with a multitude of connectors to other technologies and pre-made helpers. In this post I’m going to show you how to integrate the authentication part into your Vaadin application, using the Vaadin CDI plugin and JBoss 7.1. The blog post is a summary of my Wiki article. It contains complete source code and a more thorough explanation on the different parts.

So, how do we really make this work?

There are a couple of ways we can configure the Servlet to have both JAAS and CDI capability; both involve the actual mappings of the Servlet. If you map your Servlet in your web.xml, you can use CDI by using the CDIUIProvider utility class. It scans the classpath for @CDIUI annotations and deploys the classes automatically. If you’re not using web.xml, you can define the same thing in your servlet by injecting the provider and adding it to the session. In my example, I just use the pre-made servlet definition included in the CDI addon. It is preconfigured to use the CDIUIProvider, so I just create the necessary UIs and annotate them, and I’m good to go, like this:

 @CDIUI("secure")
public class SecureUI extends UI

That’s how you get CDI to work, what about JAAS? Well, we can restrict the user in two ways; web.xml-based security constraints, or restricting the access to mapped Navigator Views using the @RolesAllowed annotation. Since we aren’t using the Navigator, we need to use the web.xml file approach. If you already have the file, then you just add the security constraints. If not, you need to create a web.xml file under your WEB-INF folder. You don’t need to add any servlet definitions; you only need to work with URL mappings. With JAAS, you define which URLs are off-limits to normal users. If you have a Servlet deployed there or not is actually moot; JAAS only controls access to that URL, it doesn’t care what’s there. You also define where the login-page exists with another URL.

In my example I, have a secure area of my application mapped to /secure, an unsecure area mapped to the root (/), and a login page on /login. I tell JAAS that /secure is a secure zone: users must log in to access it. If a user isn’t logged in, they get redirected to a login page. In our case it is /login. The user logs in, and the server grants access to /secure. Fragment below:

 <login-config>
    <auth-method>FORM</auth-method>
    <realm-name>ApplicationRealm</realm-name>
    <form-login-config>
        <form-login-page>/login</form-login-page>
        <form-error-page>/login</form-error-page>
    </form-login-config>
</login-config>

How you actually log in the user is completely up to you. In my example I use a Vaadin UI with a relational database to store user info, and have JBoss fetch the user data with SQL. You could also set up Active Directory, LDAP, a simple file-based system. You could use existing JSP (or even plain HTML) for the actual login UI. There are lots of tutorials for the different solutions, so I won’t cover them here. Check the wiki article for detailed information about the database method, including all source code and JBoss configs.

Now that you have JAAS enabled, what benefits do you get? Well, a lot actually. With JAAS, you get access to a properly defined authentication and authorization framework, that is built into all application servers. You can easily separate your security concerns into a separate, maintainable module. With CDI and EJBs, you can use standard-based security protocols for bean access. If you are using the Vaadin Navigator, you can even define access control restrictions on your Views with the @RolesAllowed annotation found in JAAS. Most importantly, using JAAS lets you concentrate on your application instead of the security for it.

That’s it, your app will now use JAAS authentication and CDI. The configuration provided in the wiki article isn’t complete, and there are small pieces I didn’t really cover, but it will work for basic cases. From here, you can add authorization for your particular application. Anything I missed? Anyone used JAAS with CDI, and want to share your thoughts? Feel free to add comments below.

The full Wiki article

Thomas Mattsson works at Vaadin as a Vaadin Expert and Project Manager. He has been designing and implementing Vaadin application architectures for over 5 years. When he isn’t designing, he runs around Europe doing Vaadin trainings and consulting gigs. You might also catch him on the Vaadin Forum.

A bit over a year ago we released Vaadin 7 renewing the framework inside out. Then came push support with 7.1. Now what?

Let’s take a look into the future. First off, we do not see C# coming up (who is this Nutella guy anyway?). With Java 8 and lambdas already well supported, we have a solid foundation that welds Java and HTML5 platforms together in the most elegant way in the industry. So let’s start building new exciting features on that hybrid platform.

Vaadin 7 series will iteratively add features to the platform while maintaining backwards compatibility with 7.0. We guarantee to support the 7-series for the foreseeable future, but at the latest until 2018, both commercially and open source.

Vaadin 7.2 - Responsive tune-up

Next up in the pipeline will be a minor release that continues building the infrastructure. Features include:

• Responsive layouts for components (currently available as add-on)
• Improved push channel with support for long polling, Tomcat 8, Wildfly 8, Glassfish 4, Jetty 9.1
• Font icons that look great on high DPI displays and are lightweight
• Native support for Internet Explorer 11 and Windows Phone 8.1. (Including pointer events)
• Lots of performance optimizations and API improvements

The beta version of this 7.2 will be available later this month. The final version should follow in May 2014.

Vaadin 7.3 - Let there be light

The next big feature is called Valo. It means light in Finnish. Just like light, Valo will define what you see, how it feels and tune your mood. This is the next theme for Vaadin. It will be beautiful.

How should it look like? Metro? iOS7? Adobe CS? IntelliJ? How much negative space? Which fonts? Dark or light? Rounded or sharp? Flat or shadowy? You tell us. Even better, you tell Valo.

The SASS compiler built in Vaadin 7 enabled us to make it modular. You can choose the pieces you like, vary their styles, color the overall theme as you choose, define how flat or rounded it is, etc. In short, you can parametrize Valo to look like almost anything you want.

Some of the defaults for Valo

The first Alpha version should be available later this month. Beta should be available in May or June 2014 and the final release should follow in June.

Vaadin 7.4 - Son of the Table

Table has been the key component in Vaadin since day 1. While it has served Vaadin extremely well, we must raise the bar. Welcome Grid.

Grid should fix everything that you feel is missing or wrong in Table. We looked at all the requests we have got during the years for what Table should do, peeked in some scary memories of how far people have stretched the component and concluded that all of this should be doable. Grid should either have the feature OR be flexible enough to allow easily to add the feature.

Simply put, we want Grid to be the best data grid for web. Par none. This sets the bar really high for performance, scalability, features and customizability. We are confident that we can make it, but it will not happen overnight.

This release will include the core of the grid. Some may call it MVP. We are looking at features like

• Super fast hw-accelerated Escalator rendering engine
• Unlimited number of rows
• Fully functional API for both server-side and client-side use. Yes, we are looking at you GWT-folks.
• Easy to extend - both in client and in server
• Editor rows for powerful lightweight cell editors
• Frozen columns
• Hierarchical headers
• Customizable widgets and components in headers
• Customizable renderers for drawing anything inside cells

Strictly speaking, we do not know when we are ready with this release. Sorry. First we though last Dec, then Feb, June looks like it. One thing we do know is that we'll start shipping alpha builds later this month. And after that every two weeks until we are confident enough to call it beta.

Vaadin 7.5 - Grid strikes back

7.5 = 7.4 + 0.1. It is that simple.

In this case the 0.1 is planned include the rest of the features we want to get in Grid. At the moment we anticipate the list to be:

• Hierarchy support (should contain all features in TreeTable)
• Variable row height
• Using parent scrollbars to simulate long pages
• Supporting undefined sized data-sources by loading rows when scrolling to end
• Components and widgets in cells
• Detail rows

The schedule for 7.5 is clear: it comes after 7.4.

Vaadin 7.x - Steady stream of features

Yes, there will be 7.6 and 7.7 and so on. We are just getting started with Vaadin 7. While we have tons of ideas of what we would like to be in these releases, we have to deliver the already outlined releases first before stating to pinpoint these features to certain releases.

Vaadin 8 - Future Web

Thus far we have been keeping our lips sealed on Vaadin 8. Saying that we will not even start thinking about it any time soon. We failed. Some thinking has been done.

With so many wonderful things like shadow DOM, custom elements, web components and the latest developments in CSS, it is hard not to be excited about the future of the web. Unfortunately the reality is that these features do not work in today’s browsers and there will be some poor fellow using yesterday’s browsers tomorrow. Especially in the enterprise world. And in the end, You, our dear friend, try to build a wonderful user experience for a customer who wants it to work in "all browsers".

With Vaadin 8 we will take a peek into the future of web. We'll take bold steps forward and leave guys with yesterday’s browsers behind. Maybe even leaving the guys with today’s browsers behind. And then add everything wonderful that is possible in tomorrow’s browsers directly in Vaadin.

Scary? What happens to those poor guys mentioned above? What about the customer who wants it all? For them, and for You, our dear friend, we have Vaadin 7 series. That will be supported and developed in parallel, until Your customer is ready to jump to Vaadin 8.

Roadmap

Originally we wanted to ship all of the above in just one release called 7.2. Shipping estimates started sliding faster than the Olympic Sleds when we realized the size of the effort. Finally we decided that shipping early and often is far more valuable than the blasting sound of the dropping on an anvil-sized release.

For an updated Vaadin roadmap, take a look at our public roadmap at vaadin.com/roadmap

Update: For popular demand, here are some links revealing more of Valo

• A huge screenshot of Valo
• Pre-release source code of Valo
• Pre-release backport of Valo to Vaadin 7.1 with Live demo