Hello everybody. 1st April is over and no worries, we won't stop JVx

Today is a great day because I'm very happy to announce JVx - version 2.0.

It's an awesome release because JVx 2 contains so many new productivity features. It's still a small codebase and the quality is very high. We made a big step forward and want to show you some details.

First of all, the LoC analysis. Here are some very interesting numbers for you:

This time, we broke the mark of 100.000 LoC (112.507). We thought it would be possible with 1.0 but now it happened! Our code is still well documented with about 42% of the LoC.

Some additional numbers:

Files and Tests

JVx library source files   501 Swing UI source files   132 Test source files   109 Total   742

Still a small codebase and still very easy to maintain.

Unit tests (no UI, without manual perf. tests)   592 Class coverage (without UI)   78% Method coverage (without UI)   66%

TOP 10 classes

This is amazing because we have so many features and so less code. I think our quality standards have been met!

And last but not least, a short overview of new features:

• New metadata cache

  The caching mechanism is now a real killer feature. No ORM library or any other DB API has a similar technique. JVx is unique in this area. What we do? We reduce database calls and requests. We have different cache levels like Global, per Session or per Connection. The cache is a learning cache and your application will be super fast in production mode.

• Improved Constraints check

  Our linked cell editors (comboboxes, drop-downs) now shows columns from tables referenced via Foreign keys. Now the master table shows columns from tables referenced with Foreign keys. And also the resulting comboboxes show columns from referenced tables. If you have a clean database model, simple use your master table and the GUI is ready. If your database model isn't as clean as it could be, simply define your references with our APIs.

• Cache mode for Security Managers

  Before JVx 2, a security manager was cached globally per application. Every session was checked with the same security manager. With JVx 2.0 it's possible to have a security manager per client. Every client could have its own security manager instance.

• Focus listener support

  This is not rocket-science but important for all kind of UIs. Now JVx has support for it.

• IController and IControllable

  This is completely new because it allows data navigation with centralized controls. Read more.

• NO more session blocking

  Before JVx 2 the server implementation blocked simultanuous calls via DefaultObjectProvider. This wasn't a real problem for Desktop applications and with few users but it was in Web environments - especially with our Vaadin UI - or with e.g 500 users. This blocking is gone.

• Session isolation

  Usually, a session has a specific Life-cycle object with business objects and actions. Such Life-cycle objects have direct access to the MasterSession of an application for convenience. If you want Life-cycle objects without access to the MasterSession this is the right feature for you.

• New layout: UIGridLayout

  The layout is row/column oriented like good old AWT GridLayout.

• Super-lazy-loading

  If you use down and up keys to navigate in tables with details, you'll be surprised. The standard lazy-loading mechanism loads data in blocks and on-demand. If you had master/detail relations in your screens this wasn't enough because every master record change did load the detail records. With JVx 2. this will happen if you release the down or up key. This is a nice productivity feature.

• CheckBox CellEditor

  We now support "real" Checkboxes as cell editor. Our choice cell editor is image based and it doesn't support LaFs. Of course, with the right images it might look like a native Checkbox. Now you can use native Checkboxes. We recommend the choice cell editor for columns with multiple possible values, e.g. Yes, No, null. The Checkbox only has two states Yes or No.

• MetaData customization

  With JVx 2.0 it's possible to set/change MetaData per Storage, e.g. add a Primary Key.

The list is not complete but shows biggest changes and all details are available in the Changelog.

Please download JVx 2 and send us your Feedback.

Our upcoming release of JVx - version 2.0 will provide a nice new feature. It's a special record navigation for databooks. If you know Oracle Forms applications you should know what I'm talking about. For all others, a snippet from an Oracle Froms application:

Oracle Forms Navigation

We'll support similar navigation via JVx for our databooks without changing your whole application:

JVx Navigation

To support this old-school record Navigation, we introduced two new interfaces (IController and IControllable). If you need more details, read the Feature Request.

You should know that your existing applications won't change automatically. JVx has full support for new navigation but doesn't implement a UI for it. If you want to use it, you have to add your own controls like:

In your application init method:

And that's all you need. Don't change your screens or your UI controls. Everything will work out-of-the-box.

The event receiver should be an instance of javax.rad.application.genui.ControllerContent. Our Application javax.rad.application.genui.Application and javax.rad.application.genui.WorkScreen are ControllerContents. So it's very easy to use existing actions. All available actions are defined and implemented in ControllerContent, like

If you want to know the current state of an action command, simply ask:

If you want a different handling than already implement, simply overwrite the method

and do whatever you want, e.g. hide buttons instead of disabling:

No worries, we still prefer record navigation directly on the UI control:

Control Navigation

because it's easier for end-users to find the right buttons.
But especially Oracle Forms users will love the new Feature

First of all, we don’t have JVx 2.0 for you. We planned it for 2013 but it wasn’t possible to finish everything.

We made some smart design decisions and put more time in our vaadin UI (especially push support) and our Liferay integration. Especially LR integration is now incredibly good. We support Live Preview of work-screens without deployment. It makes developers happy!

Sorry for the delay, but we have some nice extra features for 2.0 in the queue like buffer caching for queries.
Our plan is that JVx 2.0 will be released together with VisionX 2.0. This will happen in Q1/2014.

But don’t be sad. We have a new JVx release for you. It’s 1.2.1 (see Changelog). We also have Vaadin UI 1.1 for you (see Changelog).

VaadinUI 1.1 was built with vaadin 7.1.7. The current vaadin version is 7.1.9. We'll update to the latest vaadin with vaadin UI 1.2.

Both releases will be available on 24.12.

Merry christmas

Our vaadin UI implementation is ready for Liferay portals because vaadin has built-in support for portlets and we added some magic to our UI implementation. With our last integration project we made it possible to run a JVx screen without changes as Liferay portlet. It was amazing but there was a limitation to one screen. It wasn't possible to open screens from the portlet itself, because we didn't implement this feature.

With our current implementation, we support whole applications running as portlet. It's possible to open other screens directly from your portlet. It's also possible to navigate between screens but with full JVx security mechanism (which is directly connected to Liferay security). Now it's really amazing:

We have two screenshots for you. The first shows the embedded variant with two opened screens, but only one screen is visible. It's possible to navigate between screens via navigation links. The second one shows the window variant. Every new screen will be opened as separate window.

Screen embedded

Screen as window

We fully support Vaadin' push support with current JVx *nightly* builds (see JVx with vaadin UI and server-side push). We had some problems with manual push mode because of some strange implementations of atmosphere in vaadin. We found a better solution to be independent of vaadin changes (should work with 7.1.8 and later).

No we automatically push if you use standard threads or threads, created via VaadinFactory. It's also possible to use JVx' callback mechanism for push operations. If you won't use threads in your client application, simply make an async server call. The server implementation automatically starts a new thread and executes the task. The server will notify the client after the task is finished. This is a little bit strange because client and server run on the application server, if you use our vaadin UI. If your JVx client retrieves the result of an async call, it will automatically push the results to the vaadin client. This makes the whole application very smart and live.

It's very easy to work with async calls in JVx. Simply use a callback listener:

The server method in Session LCO:

We didn't change JVx' APIs to support vaadin push. It works behind the scenes and we simply love it.

Use our nightly builds to see how it works.

We build all our OSS projects automatically every day, but only JVx binaries were available for download so far. We wanted to let you know that we added JVx.vaadin and JVx.help to the nightly-build download area. Check https://dev.sibvisions.com/jvx.nightly/ to get access to our nightly build binaries.

Currently we only push JVx snapshot binaries to maven central, but we'll do the same with JVx.vaadin or online help in a few weeks. So keep reading this blog to get the latest news or follow us on Twitter.

Vaadin supports "push" - since 7.1 - but JVx doesn't have an API for that. It's technology dependent and we usually not need it on client-side of an application. It would be useful for the server-side of JVx applications, but that's a different thing. I want to write about server-side push for UI changes.

If you use threads in your application, to update the UI, it's not a problem if you use a desktop technology like Swing UI. The UI is always up-to-date. If you use vaadin UI, it's not the case, because vaadin UI runs on an application server (= server machine) and vaadin client runs in your browser as Javascript code (= client machine). The thread runs on the server machine and doesn't update the client machine automatically. The client retrieves all changes with next client request. This is sometimes too late. With server-side push it's possible to update the client machine immediate, if you use pure vaadin.

With our next vaadin UI release, it's also possible to use server-side push of vaadin to update the client machine. It's very easy to use and also is technology independent, but we didn't introduce new APIs

How it works?

Create a new thread, through your factory and use invokeLater to update the UI. You always should use invokeLater to update the UI (no difference if you use swing or other desktop technologies).

If push is enabled, above code pushes the UI changes immediate to the client machines. To enable server-side push, simply add following to your servlet configuration in web.xml:

It's also possible to use vaadin push without JVx' mechanism (pure vaadin). To see how this works, read following issue: Server-side refresh.

Our good old showcase application was the first JVx application, developed in 2008. It showed some features of JVx but wasn't a real-world application. And of course, it was a small application

Some month ago, we decided to create a new real-world application. And what's better for JVx as an ERP system?
So we developed an ERP application It's not too feature-rich but demonstrates the full power of JVx.

It's the first application that contains all projects around JVx. The application runs as Java Applet, Webstart (applet or application mode), HTML5 (based on vaadin 7.1), mobile REST server for mobile clients (native iOS and Android) and our rewritten Online Help. Oh, and the built-in JVx REST interface. The application is a multi-user application with a user/role management.

The ERP system demonstrates a real-world Single Sourcing approach. A fat backend with a smart frontend and it supports mobility strategies.

If you want more information about JVx and UI independent application development, visit our talk at W-JAX (Tuesday, 10:15 to 11:30, room Lillehammer)

Thanks Stefan for your great work!

Try out our new application:

http://demo.sibvisions.org/demoerp/ (Applet)
http://demo.sibvisions.org/demoerp/web/ui (vaadin based)
http://demo.sibvisions.org/demoerp/help/ (vaadin based)

Use following credentials (Username = Password):

Manager: manager
Sales person: sales

The whole source code of the application is online and available on SourceForge.

Feel free to send us your feedback!

Our JVx First Application is now available on SourceForge. In the past, we only had zip archives that contained our first application. Now it should be easier for you to start with JVx if you don't use our maven archetype.

The project site is: http://sourceforge.net/projects/jvxfirstapp/

The repository contains an Eclipse project that is ready-to use. The application itself is a database application. Please start the database before you start the application. The database is available and stored in db folder. Simply execute db/startHSqlDB.bat if you use Windows or start it manually on other OS'.

Our First Application is a very simple JVx application and demonstrates first steps without complex use-cases. It simple demonstrates user authentication via XML security manager and CRUD operations with a database table. But the project also contains a JUnit Test that shows how you could test your business logic.

A more complex application will be available in the next days. It's our Demo ERP. This application will demonstrate Swing UI, Vaadin UI, Online Help and more. It's a "real world" showcase that shows the full power of JVx.

If you want to use VaadinUI 1.0 with your maven project it's not an easy task because VaadinUI is not available via maven repositories - right now. But I want to show you an easy way to use VaadinUI 1.0 together with JVx Archetype 1.2.0.

Simply create a new maven project (my IDE is Eclipse) based on JVx Archetype 1.2.0. This archetype references JVx 1.2. Older versions are not compatible with Vaadin UI 1.0 - because of new features in JVx' launcher interface. In order to use Vaadin for JVx applications, add following dependencies to the pom.xml of your server project:

Set the global property in parent project pom.xml:

Because Vaadin runs on server-side, our client has to be deployed on server-side as well. Change pom.xml of your war project:

This is not a perfect solution because jvxclient.jar will be added. This lib is not necessary because jvxall.jar is already available - but also not a problem!

The last step is the integration of JVx' VaadinUI. There are many solutions to integrate external libraries but maven is not a friend of external libraries. Using system scrope is evil and such libraries won't be added to war files. Deploying external jars to a local maven repository works but why should we do that? I did decide to use sort of a local maven repository placed in my project with following file structure in my server project:

The integration in pom.xml of server project:

Finally we need additional dependencies (server project):

The last integration step is the modification of web.xml in our war project:

That's it.

Use the war project together with an application server in Eclipse and enter http://localhost/myproject/vaadinui/ in a web browser to start your application with VaadinUI - with debugging support. Create a war file, deploy it and it will work without problems.