CUBA Platform Roadmap 2018

I like the idea, but Vaadin 10 is still in beta. I think I would rather see them stick with Vaadin 8 and plan for a switch over for the next major upgrade, once Vaadin 10 has been released and had time to bed in.

Just my opinion of course.

Thank you guys for your interest and your kind words!

Let me answer some of the questions.

In fact, there is an old issue that we still had no chance to implement. Most probably we’ll return to these relatively little improvements after finishing major changes in 7.0.

All current Studio features will work in both IntelliJ Community and Ultimate editions. The screen layout designer will basically be the same as the current one, but it will run inside the IntelliJ window next to the source code editor.

Definitely not in CUBA 7. Vaadin 10 is a very different product and it is now on too early stage for us to adopt. Besides, Vaadin promised to support version 8 for the next 4 years, so we’ll have enough time to see how it will all go.

Yes, it will.

It would be good if Cuba would address this more concretely.

At this point Cuba Platform is now out of the running as a new platform for development for my company. There is no way that I can sell it to senior management here when it will be obsolete in just four years.

Vaadin have not helped with this. They don’t appear to have an easy migration path for Vaadin 7 or 8 users.

See Migrating to Vaadin 10 and beyond | Vaadin for details.

Even Vaadin is recommending that you stick with version 8 if you want full functionality and stability, which tells me that Cuba should be wary of starting work with something that will take a few iterations to reach full maturity.

However, yes, sticking with version 8 forever would eventually lead to a dead end, but I don’t think they said they were going to do that.

The biggest problem with the current framework is that it’s not responsive, which means building two UIs. Vaadin 10 should fix that.

2 Likes

Konstantin, I’m also interested in this. We currently use the BPM engine with some additional customizations and up until this roadmap was published, were considering doing even more. Do you plan on still using Activiti, for instance? Do you recommend holding off on further customizations?

1 Like

Hi guys,

Regarding Vaadin 8, 10, etc.

Sorry if I wasn’t clear enough. Of course I didn’t mean that we are going to stay with Vaadin 8 forever. We successfully migrated from Vaadin 5 to 6 and then to 7 a while ago, and through all these migrations our GUI API and XML schema remained relatively stable, at least comparing to changes in Vaadin. Now we are working on the migration to Vaadin 8, and again we take all the heavy lifting on ourselves. For example, the data binding in Vaadin 8 has changed dramatically, it now provides only one-way bindings. So we are now implementing the whole data binding mechanism on our side for to keep your code compatible.

We will start thinking about further migrations as soon as we complete the current one, probably next year (2019). Will it be Vaadin 10, Vaadin 20, a fork or a hypothetical homegrown framework - I simply don’t know at the moment. Anyway, we understand the importance of the compatibility for long-living enterprise projects, so it is always our priority.

Regarding the BPM addon. We are now evaluating two ways of improving it:

  1. Continue with the current implementation based on Activity. Upgrade to the latest version and put efforts into improving the API and usability.

  2. Switch to Camunda or Flowable engines and modelers. Make significant changes in the integration architecture if we decide that it is needed.

Both ways assume that the current processes will continue to run. In the second approach, a new BPM-2 addon will appear, but the current one will be supported too, just without further active development. So I wouldn’t recommend you waiting for the new implementations if you are already using the BPM addon or planning to employ it in the near future. All your processes and business logic will continue working as long as they use the current public API, possibly requiring minor migrations. However, I’m not sure about your customizations, it depends on what you are doing.

4 Likes

Hi there, Konstantin

What do you see as the advantages of going from 7 to 8, rather than sticking with 7 then going to something more responsive a bit later?

Is there something in version 8 that is a must-have?

P.S.

This is the best forum setup I’ve ever seen. Is it your own work?

1 Like

Hi,

We want to use Vaadin 8 in the platform because of several important features:

  • New URL routing mechanism
  • Support for HTML5 History API
  • TreeGrid component

Also, we want to get latest updates due to bug fixes, performance improvements and security patches.

In addition, there are things that we would like to use in our projects and products:

  • Drag and drop in Grid
  • Drag and Drop interoperability with other apps
  • HTML imports
  • Eager field validation
1 Like

Thanks for the update, Konstantin. This is all good to hear! Keep up the great work over there.

Re Kotlin support, I understand that for you it is only an “opportunity”, from a purely developer perspective, and I agree.

But let me add that it could (potentially) be huge for marketing. I mean, Kotlin is very hot at the moment, especially after the official Google adoption for Android, or Gradle before that, etc.

Adding support to Kotlin in the gradle plugin (so for IDE only development) is a little effort IMHO, on the other hand I know that will be harder adding full support to Studio (automatic code generation, etc.).
In the meantime you could add Kotlin support to the IntelliJ plugin, so to have some “magic” at least in the IDE.

Announcing even a small step towards full Kotlin support, will then lead to mentions in popular Kotlin channels, communities, etc. raising the awareness of CUBA.

Just my 2c :wink:

3 Likes

Something else I’d be interested to hear more about is the support for alternative Javascript frameworks (though I can understand that it might be too early to talk about that). I’ve played around with the Polymer stuff, and I see it as something to add components to another app framework, rather than something I’d build a whole front end with. So support for a React or Vue module as part of the Cuba project would be great.

Our aim is to introduce more generic support for front-end clients in terms of build system and Studio templating. It will be possible to add client based on arbitrary framework, though Polymer will remain basic. I hope I can reveal more details soon.

2 Likes

Thanks. I look forward to hearing more about it.

Great features on the list.
Is there any possibility to bring visual designer for Polymer 3, something similar to currently available for generic UI designer today in CUBA?

1 Like

Is there any possibility to bring visual designer for Polymer 3

Having one is one of our initial goals since Polymer has an official designer and more lightweight wizzywid. However both are not production ready and not up to date since Polymer team is busy on Polymer 3 release preparation. We keep an eye on the progress of both projects and will consider integration as soon they are more polished.

1 Like

I see what you mean: Designer hasn’t been touched in quite some time.

Hi Konstantin,

Thank you for clarifying my concerns with Vaadin/IntelliJ.

Are you able to provide any details regarding my (and Ryan’s) concerns with the new BPM?

Thanks!

Hi Keith,

At the moment, I cannot add anything to what I wrote in the comment above. I hope it clarifies our general approach.

Whoops. Sorry, I missed that comment. Thanks!

Hi @knstvk
Camunda BPM looks interesting. It also has extensive email integration.
Anyways, will this be possible in the enhanced version as follows which is used in any enterprise environment:

-put on hold by approver with specified number of days and if not actioned within that duration it reminds by email notification automatically
-automatically escalated to the manager of approver if not actioned within certain numbers of days which will be configurable
-option to build reusable workflow across different entities
-task list by users grouped by task type. This task list would be a gateway to display and action (approve, reject, forward).
-Count of such pending actions can be displayed on a badge for respective users notice
-option to display workflow node from task list and it’s approval status
-option to trigger reminders to immediate approved on adhoc basis apart from notifications