We didn't have support for Buttons with popup menus in JVx because standard Swing doesn't support this feature out-of-the box. But such a component would be very useful for some UIs.

We didn't change our UI definition but we started with support in Swing. Our JVxButton now has support for showing a popup menu. It could be like this one:

DropDown

We've added some buttons to VisionX, because it reduces the amount of buttons

VisionX with new buttons

It's easy to use the new feature in your Swing application and also in your JVx application (for Swing UIs):

There are some things to know:

• Set the translation because the resource is added and the UIPopupMenu doesn't have a parent.
• Call addNotify to enable translation (same problem because of missing parent)
• You should check if the resource of the button is an instance of JVxButton to be UI technology independent

If you work with above code, you'll have all JVx features like simple event handling or translation.

If you have a lot of work-screens in your application, it's not so easy to find the right screen because VisionX didn't offer search functionality in its open-screen wizard. With upcoming releases, VisionX will have such search functionality:

Screen search

The search fields will be visible if you have more than 5 screens!

Another problem with screens is that you can't search for fields or don't see automatically hidden fields, like ID columns. We have another nice search feature for you:

It will be possible to show hidden fields and also the used column name of your database table. The column names are not visible by default, but will be after you've pressed More...

Do you use a Vaadin application as portlet with e.g. Liferay and does your application create generic downloads (e.g. reports)?

If you want to download generic/dynamically created files from a portlet, you don't have too many options. You could use the FileDownloader extension or you could open a new window with the file resource. But both options are not perfect. The FileDownloader has to be connected to a clickable component e.g. a button and the new window won't be closed automatically (browser dependent). The FileDownloader is a good solution (see recommendations) but it triggers the download from the browser via user interaction. If you have dynamic UIs or if you can't use a FileDownloader because you need a more generic solution, then you could have a problem?

Our JVx Vaadin UI implementation is very dynamic and a developer doesn't use native vaadin components (until he needs to do). The FileDownloader didn't work for us because of UI abstraction. But we have a solution that might help you as well. Its comparable to FileDownloader but it's not user driven.

Simply use our extension with your UI:

The extension is not limited to UI but one Downloader per application is enough.

The source code is available in our repository.

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.