How Vaadin uses GWT UI components through Annotations

I want to know how vaadin uses GWT UI components through Annotations?

I saw there are associating Vaadin server-side components to GWT Ui components through annotations. But how it works like how compiled components gets downloaded to client side.

Please explain


All the client-side components (“widgets”) that an application can use are compiled into a
widget set
, which is JavaScript code. A widget set contains the client-side counterparts of all Vaadin components, not just those actually used by an application. The other name for the widget set is “Vaadin Client-Side Engine”, as it also contains the logic for communicating with the server-side.

When a user opens an application in a browser, the browser loads the initlal “loader” HTML page (press Ctrl+U to see it), which only task is to load the widget set and make a server-side request for the initial application state. After that, all client-server communications are caused by user interaction with the widgets.

For each client-server request, the UIDL response contains a component tree (entire or fragments), which specifies components and their states. The client-side engine needs to recreate or “paint” the component tree in the browser by creating the client-side components specified in the response. The mentioned annotations specify which widget is created.for a certain server-side component. (The widgets are not loaded to the browser at this point as they were loaded with the entire widget set all at once.)

To expand on this a little:

At widgetset compile time, a GWT generator (WidgetMapGenerator) in executed and creates a static mapping from the annotations to what is essentially a switch-case structure in a generated class within the widgetset. There is another thread on the forum about how the annotations are looked up in the server side code during widgetset compilation.

At runtime, the server informs the client of the mapping it uses (which numerical component type corresponds to which branch in the above mentioned switch-case structure). Thereafter, the server only uses these numerical IDs to refer to component types and the client side engine creates the appropriate “class” instances based on them.

All this is transparent to the user, hidden mostly in the WidgetMapGenerator and DefaultWidgetSet classes.