Widget to server communication in Vaadin 7

Vaadin 6 / 7 / 8
1

Hi there,
I’m currently playing around with the new Vaadin 7 way of creating custom components. There’s one thing that I still do not fully understand after reading the tutorials from the Vaadin 7 wiki. As far as I understand, transferring state from the server-side component to the client-side widget goes through the Shared State object but not vice versa. That is, a client widget such as a Field component has to transfer its data through other means to the server. In the current Beta 11, this is still done by the Connector classes with the deprecated Paintable interface using the Vaadin 6 style with ApplicationConnection. I assume this will be removed for the final Vaadin 7 release?

My question is now, what is the preferred Vaadin 7 way for a Field component to send its Field value to the server? Will this be done via explicit ServerRpc calls or was I wrong with my assumption that the Shared State is only used in a unidirectional way?

2

From the wiki:

So, yes, you are correct, Shared-state is an unidirectional way of communication. For transferring data back to the server, you need to use RPC.

3

Some components have been fully converted not to use the old Vaadin 6 style communication mechanisms but others not yet.
The remaining components and mechanisms will not be converted for Vaadin 7.0 but probably for later 7.x.

4

Thanks for your replies. Seems like I should have reread the wiki more thoroughly :wink:

So I assume that the RPC mechanism will be the recommended way to communicate state changes back from the client to the server and that the insertion ‘currently’ in

does not mean that this is going to be changed in the final version of Vaadin 7.

5

The reason for the state only being communicated from server to client is possible problems with consistency if both sides change it simultaneously. Originally we did evaluate also options with two-way shared state.

There is no generic way to resolve all conflicts without at least in some cases losing information that might be the “wrong” thing to throw away, so we decided to make the server state the master state and use RPC from client to server to avoid losing client side changes when the server modifies the state. There are still some situations where simultaneous changes might cause problems, some of them resolvable by component implementations.

6

Thanks for the clarification on this topic. This makes things a lot clearer. I didn’t see this problem from this point of view yet, but it makes total sense in that light.

7

Another question came up for that topic. When I use ServerRpc to transport my client-side state changes to the server, how do I best handle the immediate mode. For instance, when I write some client-side text input widget which sends its input to the server component through an own ServerRpc interface. Should I then use two methods in the RPC interface, e.g. setText() and setTextImmediate() where the former is annotated with @Delayed? Or is there some other recommended method for handling whether a component is immediate or not?

8

You can do so, although Vaadin 7 is phasing out a little the concept of non-immediate fields.

A component not being immediate never guaranteed a delay (the client treating everything as immediate and ignoring the flag would be consistent with the specification) and caused a lot of confusion. Furthermore, while immediate changes cause a little bit more network traffic, they can improve the responsiveness of the UI slightly when e.g. the save button is clicked at the end as other data has already been sent.

Note that immediate changes are collected within a (small) time window in Vaadin 7, so multiple immediate calls within some milliseconds are collapsed to one message over the network. This also reduces the overhead of having mostly/only immediate components.

9

Maybe somebody could tell me how arrays or more complex structures are synchronized via SharedState? Docs ignore is as if it is not a question at all saying just that they’re “supported”. Still ComboBoxConnector, TableConnector (and others I beleive) use deprecated Paintable in 7.7.3 to update the list of it’s items… Obviously it is impossible to recreate whole contents for a widget if something was changed on the server.

10

I’m trying to implement a custom text editor / viewer which handles large chunk of characters (for example a lengthy article) on client-side and upon user request (click a button) send the content to server side. The editor is able to annotate texts and automatically scroll to certain texts, etc… so it cannot be implemented by RichTextArea.

And I found this post with the same questions asked by Roland, it’s very valuable and clearified a lot questions that I have.

However, if Vaadin 7 is phasing out a little the concept of non-immediate fields, I still cannot just send the whole chunk of characters to the server everytime user changes just a little bit… server does not need to know the small changes, and that may be a lot of characters to send through the wire…

So, my custom widget needs to know when to send the text. That is, upon user click a button.

Then, one solution is: user click a button, event sent to server, server call MyEditor to update its event, which is send back to MyEditor at client side, MyEditor make a RPC call, send the text. Ok, so I assume that RPC is IMMEDIATE, right? Otherwise I need to wait user click something immediate to receive the text.

Another solution, I include that button with my text editor and react on the button. That’s strange, why a TextField should come with a button?

I think we cannot ignore the fact that there’s an Internet between the client and server, and cannot just pretend the browser is like a display connected to the server. Maybe the “immediate” mechanism is insufficient to reflect the application logic. May I propose another model for consideration of Vaadin?

How about createing something called a “TransactionUnit”? It has server-side and client-side. Serverside UI components can be associated with a server-side TransactionUnit, and therefore the corresponding client-side widgets are also associated with the corresponding client-side TransactionUnit, so they form a group. (1) the client side TransactionUnit cache state change from client widget, queue RPC calls, etc. (2) when any of the widget in the group asks to flush the queue (immediate), everything is sent to server, (3) TransactionUnit also allows certain logic being executed in client side, for example, change of one component results update of another. This is like “grouped immediate”. And it does not need to change the current API. When developer does not use this mechanism, everything is associated with a default TransactionUnit, which behaves the default way.