chaining event handlers

I need to implement the following use case
On the server side there are number of processes which have to execute sequentially (process1->process2->process3->…)
On the client side the user clicks a button to trigger process1
When the process1 is done user gets a message “process1 is done. now starting process2” and process2 is triggered
Similarly when process2 is done user gets a message “process2 is done. now starting process3” and process3 is triggered
and so on
What is the best way to do this?

Initially I tried implementing it this way but it did not work as expected.

Create one button for each process (button1, button2, button3,…)

button1 event handler
a) starts process1
b) when process1 is done it updates a label with message “process1 is done. now starting process2”
c) triggers button2 event handler (using

button2 event handler
a) starts process2
b) when process2 is done it updates the label with message “process2 is done. now starting process3”
c) triggers button3 event handler (using
and so on.

this works partly
process1 , process2 and process3 are properly started but the label is only updated at the end of the last process.

Put a ProgressIndicator in your UI when button1 is clicked. Then just call startProcess1, 2, and 3 in sequence without using

What you want to achieve is to have some background processes that run asynchronously and intermittently update the UI. This will not work with the scheme you described since you are trying to execute all of your background processes in one event handling cycle of Vaadin. When a Vaadin client-side event (e.g. a button click event) is sent from the browser to the Vaadin backend, Vaadin will call all registered event handlers for this event and as a very last step update the UI with the values changed in these event handlers. When you trigger the event handlers of other buttons during the execution of your first button’s event handler, all of this will only happen on the server side. Calling will not communicate back to the client side (see Button’s JavaDoc). So, in the scenario you describe what happens is that the click on the first button will call the server side event handlers, there you do some server side actions (update a label more than once, invoke other click event handlers, start several background processes). At the end of this chain, your original event handler is finished and as a result all the intermediate changes to the UI state are eventually communicated back to the client. That’s why you only see the end result of your three processes.

The solution to your problem is to use some sort of server push where your first event handler will return directly after having started process 1 in a background thread. When process 1 has finished, the server has to inform the client of that through a client RPC mechanism that updates the labels on the client side (ICEPush addon, Vaadin 7 Client RPC, Websockets whatever). Only then your processes really run asynchronously.

Roland thanks for the detailed explanation.
I was hoping that the event would happen on the client side so that it could then be used to generate request response cycle.:slight_smile:
Like Johannes suggested, I could probably use the progress indicator but some how polling, creating separate thread and an async process seems overly complicated for my simple use case.
I was hoping for something simpler.
In java script I can easily implement this use case by using XMLHTTPRequest - send request, wait for response, send the next request and so on.
It would be nice to have a vaadin component which can fire an event multiple number of time, in sequence, until a count is reached or a condition is met.
Similar to progress indicator but which instead of being triggered by a timer it is triggered by the response to the previous event

That wouldn’t help you very much, I’m afraid. If you automatically triggered a new event in the response of some other event, you would have the same effect as polling with the ProgressIndicator. Except that this type of polling would be uncontrolled and would consume an awful lot of bandwidth and processor time. It’s basically the same as Busy Waiting in a loop that does nothing but check some condition. It’s not really what you want. If you want an easy way to implement your use case, use ProgressIndicator. It already has all you need.

I will try out the ProgressIndicator…
But I still think the control I described might be more efficient, at least for my kind of use case, than a ProgressIndicator.
Maybe I did not describe it properly.
Here is some pseudo code which might help explain it better.
Let’ call this control MachineGun control (it fires events one after the other … hehe)

//create an instance, add a handler, attach to a container
MachineGun mg = new MachineGun();
mainWindow.add (mg);
//within some event handler, say a button click handler, start this control
mg.enable(true);// this fires a MachineGun event
//within, MachineGun Event handler
if (timesCalled == 1){
	label.setCaption("Process1 completed. Starting process2");
	mg.fireAgain(true); //when control or response returns to client fire again
}else if (timesCalled == 2){
	label.setCaption("Process2 completed. Starting process3");
}else if (timesCalled == 3){
	label.setCaption("All Processes completed." );
	mg.fireAgain(false);//stop firing 

As you can see no polling is involved.
The event is only fired three times, unlike a Progress Indicator which might be fired many more times depending on polling interval and duration of various processes.
Most of the time the application would be in wait state waiting for a process to complete.
Now I do not have any experience writing a vaadin control but I would assume this should be relatively easy to implement.

Ok, I see where this is going. In your case, ProgressIndicator wouldn’t be the best choice, indeed (even if you could make it invisible and only use its polling mechanism). But anyway, you have to keep in mind that you want to orchestrate an inherently asynchronous process here. So, in the pseudo-code you provided, you are trying to run through this asynchronous process in a synchronous manner. For your users this would result in a blocked browser window after process 1 has started. They would see the browser’s loading indicator until the first process has finished and so on.

What you want to achieve is to start some long running process on the server that repeatedly reports its status back to the browser from time to time (between the individual process steps). In this scenario, you have exactly two options:

  1. If your users cannot use an HTML5-capable browser: you have to resort to polling where the browser repeatedly asks the server whether one of the process steps has finished.

  2. You have the option to code for HTML5-capable browsers: using WebSockets, the server itself can directly contact the browser and tell it that one of the processes has finished. Using Vaadin 7 you have the option to use
    where you can send events from the server to the client.

For my use case, blocking the browser while the process execute is perfectly acceptable because the application is all about running one process after the other sequentially.
I think the basic issue here is that I have a business use case which is inherently synchronous but given the nature of browser/server interaction and the controls available I am forced to use a solution which is inherently asynchronous.
The control I am suggesting partly solves this problem.
It is not perfect.It forces the developer to think in terms of client and server and I do not like that as that seems to go against the basic philosophy of Vaadin.
Anyway I think I will try my hand at creating the control and see what happens :slight_smile:
Thanks for all your help.

A quick update on this.
I recently came across a VAADIN like framework called
ZK Framework
Like VAADIN it provides a server side, java based AJAX programming model.
Now it provides something called an “EchoEvent” feature.
“EchoEvent” generates a client side event on receiving a response from the server.
This is exactly what I had in mind and is a perfect solution for my use case.
Here’s an
of this.
Here’s a
of this.
IMO this, or something similar to this, will be a nice feature to have in VAADIN