Why I would not use CUBA Platform (yet)

Ideas
#1

Hi,

CUBA Platform is one of the best development tools I have come across. At this stage, I would be not use it for actual development for one main reason.

Firstly about myself as a developer
I am not grounded in Java. I came across CUBA looking for an enterprise RAD tool. I think CUBA can be a great tool for non-Java Programmers as well.

Why I would want to use CUBA Platform
I would like to use CUBA Platform to develop fairly large applications that could have up to 50 entities and 200 screens with a development team of 3-5 developers who may or may not have strong Java experience. The developers will work with Cuba Studio and Eclipse IDE.

Why I would not use CUBA Platform
I will keep on monitoring the progress of CUBA Platform but for now I would not use it for production code. This is because screens require too much “heavy-lifting” code if one is not using the “standard screens”. This is my observation from looking at the samples and trying to create more advanced screens myself. With 200 screens being developed for an enterprise application, I would have a bit more comfort if most of the screen manipulation code is auto-generated, with only some custom coding here and there. I would want to have most of the “heavy-lifting” code for the business logic.

In short, what I am suggesting is more scaffolding options for screens in addition to the standard screens. Those screens don’t have to work “out of the box” but CUBA Studio should generate the basic templates for some common screen patterns and the developer should fill in the details to make the screens work together.

Example
An application has Customer and Order entities.
On the Customer browse screen, there is an “Order List” button that invokes a call to the Order browse screen with a parameter for the Customer in order to display only orders for the selected customer.

It would be great if CUBA Studio has an option to generate the two screens together with the code to pass and receive parameters. In the same way, one can generate screens for other patterns like lookup screens as well. This will allow a team of inexperienced programmers to develop a big chunk of the application as follows: create entities, create views, generate screens and write some code in controllers. Only 1 or 2 of the developers on the team will write more advanced code and implement services.

CUBA Studio can go a step further and add options to generate service bean templates for persisting an entity, retrieving entities from the database etc. I’m not advocating for a codeless platform, it’s just that once CUBA Studio is able to generate most patterns for a trivial application, it would be a good foundation to create more advanced applications. If a lot of the code in the sample applications can be reproduced with scaffolding. I would have that level of comfort to use CUBA Platform in production.

#2

Hi Willie,

i think that you have some valid points here but there are others that i just want to give my two cents.

Regarding the “heavy lifting for not standard screens”:
Well, in some sense you are right. Compared to clicking “generate standard screen” in studio creating a screen like the security groups browser is much more effort, because you have to program (sometimes just create just more XML declarations, sometimes even programatic definition via the controller). Although with the screen designer in studio will handle a pretty broad amount of scenarios via a “fast” UI.

But compared to other options, creating a screen in CUBA that is more sophisticated is very easy. If you have ever tried to create a custom UI with something like Angular JS & Bootstrap or with HTML based solutions - even with something like Android or Java Swing, you probably know what i mean. The programming model of Vaadin does not require the application developer to do a lot of “plumbing” regards client-server communication, which is a great benefit in terms of productivity. So in this sense i don’t think it is much “heavy lifting”.

> I would have a bit more comfort if most of the screen manipulation code is auto-generated, with only some

custom coding here and there

Well, but if you say that the screens that you want to create are custom or advanced - this implies that they are exactly that: custom. In this case is just not possible to generate this. Or is it more that the 200 screens are more or less the same, but they are different from the “editor” / “browse” pattern that CUBA has build it?

> In short, what I am suggesting is more scaffolding options for screens in addition to the standard screens. This is a thing i can support. I think they are working on it (i read that in another forum question a while ago i think). To be fair, there are possibilities to adjust the code that gets generated. But what is currently not possible, if i'm correct, is that the "editor" / "browse" pattern itself can be adjusted. > Those screens don't have to work "out of the box" but CUBA Studio should generate the basic templates for > some common screen patterns and the developer should fill in the details to make the screens work together.

Generally i think scaffolding is a double edged sword. Although scaffolding gives you a direct productivity benefit it at the same time is normally a missed opportunity to create an abstraction (like a Superclass for a common controller). This is why i think scaffolding should not be overrated. For my personal taste scaffolding could be a little more expanded in studio.

Additionally it’s up to you to create your own gradle tasks that will do exactly the things you imagine to be scaffolded - so you have more that just one option here.

> On the Customer browse screen, there is an “Order List” button that invokes a call to the Order browse screen

with a parameter for the Customer in order to display only orders for the selected customer.

I think this is a very good example, because it shows the different options that you have in CUBA to do something like this.

First of all, if the order relationship is a composition of a customer studio will generate a table within the editor of the customer.

The next option is that you create, like you described a browser for orders that is parameterized with the customer (actually there are a few options to get that working technically - a few can be found here: [url=https://github.com/cuba-platform/sample-screen-manipulation]https://github.com/cuba-platform/sample-screen-manipulation[/url]).

Then you have the option to use the generic filter mechanism of the order browser to filter by the associated customer (see: [url=https://demo.cuba-platform.com/sampler/open?screen=related-filter]https://demo.cuba-platform.com/sampler/open?screen=related-filter[/url]).

The last option is that you use the related entities button for tables where you can do exactly that as well: In the list of customers select a single or multiple customers and select “orders” in the related entities button.

So it depends on what you want to achieve, how much custom coding you want and how customized the UI should be - but all options are available and it’s up to you to select the right in your case.

Bye,
Mario

#3

I think it is a very valid point that Studio should have more options to customize scaffolding - and we will certainly work in this direction. For example, we are going to implement different layout templates, options for how to display related entities, easy scaffolding for various UI events. Also, we will improve API in order to make application code more straightforward and less “heavy-lifting”.
Thank you for your feedback, we will certainly take it into account.
As for a simple no-code solution for working with related entities, take a look at the RelatedEntities component:
https://doc.cuba-platform.com/manual-6.2/gui_RelatedEntities.html
https://demo.cuba-platform.com/sampler/open?screen=simple-relatedentities

#4

Thanks a lot for the feedback guys. The RelatedEntities component is something that I have missed. I will look at that.

Mario, creating Gradle tasks is a bit too much for me. I don’t really want to touch Gradle or any of the underlying technology behind CUBA. I’m glad that the team is working on more scaffolding options, that will make it an easy tool for developers like me. Can’t wait for the future releases.

#5

Low-skilled developers (or bored senior-devs which refuse to do “plumbing”) will struggle even for simplest tasks like an image-display:

And making things simple is obviously of no priority for Haulmont.

That’s why I agree, CUBA is not usable in many environments. It promises more than it can fulfill.

#6

The “solution” that I found for now is to use CUBA only as a REST-enabled backend and let the developers code the UI using more flexible tools.

1 Like
#7

@willie Nandi, sounds pragmatic & rational. May I ask which UI tools you’ve choosen (it seems we’ve similar requirements, you can answer me on info@lazaridis.com if you prefer).

#8

I haven’t started using it for a real project yet. However, I did start a small project and was able to do the login via REST API V2 using HTML/CSS/Javascript. You can use your favourite Javascript framework like Knockout JS or Angular JS etc.

I also inserted a PHP middleware server between the frontend and Cuba Platform, so the PHP middleware will implement APIs to access the Cuba APIs. The PHP will handle errors, session management, data manipulation, verification and other coding. This keeps your HTML/CSS/Javascript frontend code clean.

The advantage of doing it that way is that you can reuse your PHP middleware for various projects and your UI developer doesn’t need to know Cuba Platform.

1 Like
#9

Hi,

i just wanted to mention in case you are not aware of it, that in CUBA 6.4 there is native support for a polymer based UI: https://www.polymer-project.org/

So, basically you get best of both worlds. Lots of flexibility for your frontend (since it is just javascript) and also scaffolding (which is what is normally lacking when seperating FE and BE totally like in a angular app).

Bye
Mario

1 Like