As you already might have noticed we have published the new minor release of CUBA platform and Studio. The new version introduces mostly enhancements of the existing functionality, however, there are a few useful features have been included in 6.5.
This article covers major enhancements of Platform and Studio. The full list of changes is available in the corresponding release notes:
Let me start from a very awaiting part, according to the inquiries we get from the community.
Since 6.5 version distribution of your CUBA applications becomes trivial with the support for the Uber JAR feature. Now, you can simply specify configuration in CUBA Studio or your IDE and build JARs in a few clicks.
To start the application you only need to run two statements from the command line:
java -jar app-core.jar
java -jar app.jar
Uber JAR encapsulates all required dependencies as well as a lightweight HTTP Server. More information can be found in this chapter of our documentation.
The collection of visual components is replenished with SuggestionPickerField. The component is designed to perform search in the background and pop-up a list of suggested values while the user input.
While the post-delivery support stage it could happen that due to simple refactoring of entities/attributes names the generic REST API cannot be compatible with the old clients (e.g. mobile app) or 3rd party integrations.
The new version has introduced the mechanism of REST request transformation. Now transformation rules can be defined in a simple XML format, explaining the system what naming should be applied over the requests from the old clients.
So, if we rename the OldOrder entity to NewOrder as well as its date attribute to deliveryDate and delete the discount field, using the following transformation XML we can keep compatibility with the clients, which use the old API:
Learn more about this feature in the documentation.
<?xml version="1.0"?> <transformations xmlns="http://schemas.haulmont.com/cuba/rest-json-transformations.xsd"> <transformation modelVersion="1.0" oldEntityName="sales$OldOrder" currentEntityName="sales$NewOrder"> <renameAttribute oldName="date" currentName="deliveryDate"/> <toVersion> <removeAttribute name="discount"/> </toVersion> </transformation> </transformations>
Before 6.5, there were no proper balancing between web and middleware tiers. So, a web block were choosing a middleware server from the list specified in the cuba.connectionUrlList at startup and didn’t change it until it became unavailable.
Now the balancing applies on the level of a user session. A middleware server is being chosen randomly while the first remote connection. An established session is "sticky", so it keeps the same middleware server for its whole life time. If a request is sent from the anonymous session or without any session the "sticky session" approach is not applied and the request goes a random server in the cluster.
In some certain case you might need to define your own balancing rules. Now it can be achieved by providing a custom implementation of the the cuba_ServerSorter bean, which by default, uses the RandomServerSorter class.
With the help of this application component, cluster configuration management is hugely simplified. The component integrates your application with Apache ZooKeeper - a centralized service for maintaining configuration information. The only thing you need to do to manage the cluster topology is to specify the address of ZooKeeper. Since it is done Middleware servers will publish their addresses via the ZooKeeper directory and the discovery mechanisms provided by the application component will request ZooKeeper for addresses of available servers. If a middleware server goes down, it will be automatically removed from the directory immediately or after a timeout.
According to the activity on the support forum more and more people have started using our integration with Polymer framework. In this release we have added a few features, intended to make development more straightforward.
First of all, now, when calling an entity instance for editing from a list, it will route you to an editing form, located at another URL. This approach enables the standard browser mechanism of history tracking, so you will be able to move between a list and an editor by clicking the go back and go forward buttons in your browser. Another use of this feature is that you can share a link for some certain entity editor with other users, so they can open this screen directly by calling the link.
Next feature is the cuba-lookup component. It allows users to specify an entity instance for a reference attribute not from dropdown list, but from a popping up screen (lookup screen) with the list of entities. Find more information on this web component here.
Finally, there is a new element available in the library of visual components for Polymer client. It provides an ability to upload files to the server. Since file is uploaded it will be shown as a clickable link, so users can download it. To learn more about this web component follow this link.
The bean validation mechanism is now supported from the Studio user interface. So, you can specify constraints over attributes as well as messages to be shown when a value doesn't comply to the constraints.
So, to be sure that a string is a valid email address you just perform a few clicks in the Studio, at it is illustrated in the picture below:
CUBA Studio now supports scaffolding Entity Listeners in Groovy. Make sure you turned on Groovy Support on the Project properties > Advanced tab. Since it is on you will be able to choose what language you would prefer to code your Entity Listener.
Traditionally, let me thank all proactive members of our community, who participated the platform development and helped with testing the release candidate version. We keep our eye on the forum to be in time with most required features and benefit our community. You are welcome to watch the recorded video of the live webinar session about the release.