I'm happy to announce that our Workflow Engine will work with Oracle Forms.

The current state is beta but we'll release our Workflow engine in the next days. We found some time to test the integration in Oracle Forms and the result is soo cool. It works like a charm.

So it will be possible to embed our Workflow engine in your oracle Forms. It'll be possible for your users to design custom flows and processes. The engine itself is database driven and will work with your Oracle Forms application.

More details will follow in the next days, but here's a first impression:

Workflow Engine - Oracle Forms

It's a standard Oracle Forms window/canvas with our Workflow Designer, embedded as Java Bean.

Feel free to ask your questions

We improved the support for standard MacOS LaF in our Swing UI and VisionX. The LaF has a lot of rendering problems. We tried to use another LaF implementation but had other problems. So we decided to keep the standard Java MacOS LaF.

The problems

• The InternalFrame border problem
• The field border problem
  

  Field border problem

  A simple JTextField has a 5 pixel focus border. This is horrible because the focus is about 2 pixel. The other problem is that a JTextArea wrapped in a JScrollPane doesn't have the 5 pixel border. This makes it hard to create nice looking layouts.

  We fixed this problem:

  Field border without gap

  Looks better. One problem is that the JScrollPane doesn't paint the focus if the JTextArea has the focus. This is a LaF problem and we didn't find a workaround for this problem.

• Application Menubar

  Standard Java appliacations show the menubar in the same frame

  Application menu

  If you set the system property:

  System.setProperty("apple.laf.useScreenMenuBar", "true");

the menu will be placed in the menu bar of MacOS:

macOS Menu

We fixed the problem that setting the menu to null will keep the menu as it was.

• Comboboxes

  The height of Standard Comboboxes is wrong:

  Combobox wrong

  We fixed the problem as good as possible:

  Combobox fixed

• VisionX Toolbar height

  The toolbar height was wrong because of layout calculation problems:

  Wrong Toolbar height

  We fixed the problem and the toolbar height is correct:

  Toolbar fixed

• VisionX Wizard gaps

  The image gaps in VisionX wizards was not recognized:

  Wrong gaps

  It looks better without gaps:

  No gaps

• Wrong button rendering

  If you had a button without an image and a button with an image, the height of the button without image was higher than the button with an image. This is a LaF rendering bug:

  Wrong size and font

  The fonts are also different. We didn't know why there has to be such a difference, but we fixed the problem in Swing UI:

  Button with correct size and font

All changes are available in our nightly JVx builds

The next big update of VisionX will be available by the end of this week.

We have awesome features for you and your applications.

Some impressions:

New Web Elements		New Tutorial Apps
More Web Settings		FontAwesome Support
New Web Menubar support

More details will be available in the next days

The upcoming release of VisionX will support CSS styling. We'll show you a first impression with a short video:

The editor supports autocompletion and syntax highlighting:

VisionX CSS Editor

We did integrat the RSyntaxTextArea for this. If you want to know how this works, check the documentation.

We have a new AddOn for all VisionX users. It's the Embedding AddOn.

The new AddOn makes it possible to embedd one work-screen into another work-screen. Simply re-use screens in other screens.

Get an impression

The AddOn is commercial and not included in VisionX. Contact our sales team to get more information!

Our generic REST interface of JVx got an update.

The REST services are a powerful feature of JVx and built-in. Usually you would implement your own REST services, but JVx has the concept of lifecycle objects and the powerful action mechanism. It would be ugly to implement another layer on top of JVx just for REST services. This is a framework feature.

We had this powerful feature for a long time and it is still in use for different use-cases:

AngularJS 4 with VisionX and JVx REST services
AngularJS with JVx in action

Our REST interface just works and you are able to create microservices very fast and efficient.

But the interface has a problem with some kind of parameters because they are also generic. Suppose you have the following method:

The result type (IFileHandle) isn't a problem because JVx will send the bytes in the REST response, but the parameters: pFilter and pSort are specific types and not base types like String, Array, int, float.

It wasn't possible to call such methods without wrapper methods like:

Still not hard to solve, but parsing the filter and sort definition weren't trivial tasks. In fact, it was annoying.

We now have support for such parameters and much more. It's not super modern but an awesome solution!

Assume you have following code in one of your lifecycle objects:

The DBStorage class offers a public method:

This method creates a CSV report (address data in this example). It has some parameters for the expected filename, optional column names which should be used for the report, optional labels for the column names, the filter condition and sort definition.

To call this method as REST service, simply send a post request with following information:

e.g. URL:

(demo is the application name, Address is the lifecycle object name, adrData is the object name)

Body:

The body contains Java Code (in the JSON string).

W00t?

JVx got support for executing simple Java code. We introduced the new utility class SimpleJavaSource. It's a backport from our commercial product VisionX. The SimpleJavaSource is able to execute the given parameters and creates real Java objects. It doesn't support conditions or loops, so it's really simple - but powerful!

With our new SimpleJavaSource and the support for parameter Code, it'll be possible to call most methods without additional wrapper methods.

The SimpleJavaSource class is now included in JVx and ready to use. It's simple but powerful:

The new features will be available with our next JVx release and are already available via nightly builds.

What a great Monday
All our Vaadin 7 projects were migrated to Vaadin 8.1 successfully. First snapshots are available and we also have nightly builds for you.

We use the v7 compat layer in our first migration phase because we want a smooth and not an all at-the-same-time migration. Everything works so far and we started the next phase of our migration plan: Cleanup.

We'll replace the v7 compat layer and use v8 features wherever it makes sense and is possible. This will take some time because we expect some hidden problems, but we'll solve the little problems for you

We have awesome news for you. We'll release the 2nd update of VisionX 2.4 by the end of this week!

The update will come with some new features and many bugfixes. The most important feature is that all open source libraries were updated. You'll have access to new APIs and new feautres of all libraries. VisionX itself got some bugfixes regarding the visual designer. A great new feature is the support for AddOns with access to VisionX. It'll be possible to customize VisionX for your needs.

We also have some new AddOns and Demo Applications e.g. the VaadinAddOn which enables you to create your own vaadin widgetset/theme in seconds.

The 2.4 release of VisionX will be the last version with Vaadin 7 because we already work with Vaadin 8.1 in our development branches.

We'll also change the version number of VisionX with our next release. Instead of 2.5, it'll be 5.0.

Why?

Because VisionX is very mature and the version number 2 doesn't fit. The next release will be a major change because VisionX will contain Vaadin 8.1 and this library requires Java 8, so also our VisionX projects will require Java 8. This isn't a big change, because VisionX itself comes with Java 8. The difference is the project configuration for your IDE.

All planned changes shouldn't be a problem for you, because Java 9 is out and Java 8 is the Java version you should use for your projects. The Java version won't make any difference for our Oracle Forms users because our JVx library will be built with Java 6 - no changes for you.