Building UI's at Run-time

General
1

Our team is working on migrating an existing Swing app to the web and would like some input from the community. Thus far we have been evaluating both Sencha’s GXT library and Vaadin because we are primarily a Java shop.

Our existing Swing app has a bunch of sub applications within it but the UI for each sub application is built dynamically at run-time from a layout stored in a DB. A few of the applications are really large and contain more than 500 fields across tables and flat forms but most of the applications (~80%) have less than 150 fields.

I should also add that our Swing app contains chunks of scripted logic that are also loaded at run-time and executed during specific Swing events.

Is either Vaadin or GWT/Sencha GXT able to handle a use case like this?

2

While Vaadin views can be created in a declarative fashion (please also see the new Vaadin Designer, vaadin.com/designer) it is quite usual (the “normal way”) to create views programmatically, so why not from layouts stored in a database.

Just generate the Vaadin7 sample project in Eclipse Luna with the Vaadin plugin, and change it
slightly like the below code.

To simulate your use case I use plain reflection here – note that the “com.vaadin.ui.Button”
class name can be read from the database, or can be calculated from something read from
the database.
The same applies to the caption string.
Finally, if you have scripted logic then I assume you have an execution engine that “does
the right thing”.
In this case I made the application check for the type of the dynamically created component,
and if it is a button, add the behavior of what should happen when being clicked.
Here your execution engine can run the script downloaded from the database.
If needed, you can also manipulate other objects on the view - for example, buttons have click() methods to programmatically simulate a user click. And of course, you can iterate containers to find out what objects are there in the dynamic fashion you need.

I have not worked with Sencha GXT so I cannot help you there.

Object o = null;
try {
o = Class.forName(“com.vaadin.ui.Button”).newInstance();
} catch (InstantiationException | IllegalAccessException
| ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Component component = (Component) o;
component.setCaption(“string from database”);

    if (component instanceof Button){
        Button button = (Button) component;
        button.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                scriptExecutor.execute(dataBase.getScript());
            }
        });

        layout.addComponent(component);
    }
3

I guess our other main concern is scalability. Would you or anyone else care to shed some light on how scalable Vaadin is with very large applications containing many fields in particular numbers near what I’ve indicated in the first post?

I’ve looked at the quicktickets example, and correct me if I’m wrong here but since Vaadin manages the state of the UI at the server in the session doesn’t that mean with an increasing number of fields and UI complexity the per user session size will grow?

Doesn’t this also mean increased memory consumption at the server?

4

If you mean 500 fields on the same screen then your application can be a little slow at startup, it depends on your layout and the type of the components (a Textfield is way more light than a Table). In this case you can (in a very short time) download the Vaadin Eclipse plugin, create a new Vaadin project, create a suitable layout and add as many fields as you need; then run it and look at the performances. If it is slow you can optimize using lazy loading or splitting your layout in many tabsheet or windows.
If you mean an application with 500 fields in many screens then you should not worry: Vaadin can handle applications of every size.

In Vaadin every component has a client part (on the client browser) and a server part (in the user session in the server) so it is true that complex screen use more server memory.
A simple component (a Label for example) has a little memory footprint, while a complex component (a Table, a Tree) uses more memory.
For exmple a Table with 100.000 rows and multiple columns can use a lot of memory to hold all that data; in that case you can use lazy loading on server to fetch only the visible rows (see for example the MTable component the Viritin addon).
Obviously when you detach your screen from the UI the JVM can garbage collect it, so is not a problem to have thousands of different screens.

My biggest Vaadin application has hundreds of screens (about 20-50 fields in every screen), with 30-50 concurrent users, and we never had any problem wirh our (very small) server.
If you have very complex screen and hundreds of concurrent users you can alvays use a load balancer and multiple servers.

You can find a study on Vaadin scalability at https://vaadin.com/blog/-/blogs/vaadin-scalability-study-quicktickets.

5

Quite long time passed, but it became actual. With new microservices layer we are thinking how about implementing something like BPM engine, but fully driven by received messages from event bus and generate flows fully dynamically.

Thanks for the suggestion about how to proceed within Vaadin.

6

Thank you for the advice.


ดาวน์โหลด gclub

7

An old thread, but I figured some of you may be interested in this.

I’ve been working on a demo application with
Vaadin
 and
microservices
 using
Spring Cloud
 and
Netflix OSS
. I managed to orchestrate service discovery, externalized configuration, circuit breakers (that’s fault tolerance), client-side load balancing, replicated HTTP sessions for high availability. and a reverse proxy with round-robin or sticky sessions strategies.

The source code is
available on GitHub
 and I wrote an
article about it
.