Description of hints and fixes which help to develop custom widgets

Hints described here
are only part of the set implemented rules, constraints and configuration requirements of the framework. All these rules are configurable and you can disable any of them, change the hint severity (error, warning, ...), learn the description of each rule. Configuration settings are available via the menu item Tools-> Options, Editor section, Hints tab, Vaadin node.

Shared stat class hints

State class (SharedState subclass) is usually created with publicly available fields:

It violates the encapsulation principles but in this particular case such approach makes sense: the class is only data transfer object to share information between the server and the client. The class must be serializable and follow the JavaBeans specification. This is framework requirements. And there are rules implemented in the mentioned list of editor hints.

Of course you can convert it to the bean instead of using public fields. Just change modifiers from public to private and add accessor methods getXXX/setXXX. But it doesn't protect the fields from the modification because you still have to provide setters and resulting class will be just longer. The latter methods could be easily forgotten because you can make a constructor that initializes them once instead of writing setters. It could be enough for your case to have only getter methods.

But those methods are necessary actually because your data is sent via the network being serialized and it is recreated via deserialization on the remote end. Setter methods are required to be able to deserialize. The same situation happens with RPC methods parameters types. We are going to return back to this situation below. Waring hint is shown by the editor for status class if you have this issue.

RPC methods hints

Server->client interaction requires ClientRpc subinterface in the same way as ServerRpc subinterface is required for client->server interaction. There are editor hints and fixes available for this purpose and you can use the similar approach to ServerRpc subinterface creation described here. Appropriate hints are shown by the editor for a server side component as well as for its connector class.

Editor assistant will create the necessary interface and generate a method that returns a reference to its proxy if you start from the server component and use the fix. This link can be used in the server component logic to invoke methods on the client side.

Now you can open the connector file in the editor and use a hint to generate and register RPC interface implementation. Editor assistant finds the previously generated interface and offers to use it as a fix. The other proposed fix generates new RPC interface from scratch and uses it in the connector in the same way as already mentioned fix.

The anonymous class implementing the interface is empty because interface generated in the previous step was empty. Stub methods would have been generated if it had contained methods. Thus all the routine work on the creation and interface registration for server->client interaction has been done by the editor assistant.

RPC interface methods have some limitations. The first such limitation: they must not return any value that is their "return type" should be void. This is the consequence of the fact that all RPC calls are asynchronous and asynchronous call may not return values. There is a dedicated hint and fix for this case.

The next restriction is a consequence of the fact that client-side methods are compiled into the appropriate JavaScript methods where the name of the method is its identifier unlike Java language where the method is defined by its signature. It means that Java allows to have methods with the same name (but different parameters count/types) defined in the one class but JavaScript doesn't. This is not a an error and won't be detected at compile time but could lead to very strange effects at runtime. This situation is also detected by the editor assistant.

The last limitation in the list is requirements of JavaBeans specification compliance for RPC method parameters types which has been already mentioned above for shared state class. Those types must be serializable, have default no-argument constructor and accessor methods getXXX/setXXX for private fields. The latter requirement could be easily forgotten here. It's very natural way to initialize all bean fields in its constructor and pass instantiated bean to RPC method just beacause you can do it unlike shared state class whose creation is forced by the specific methods of server component/connector class. There is no need to have setters if you have the appropriate constructor. But this approach gives you an initialized class only on the side where you construct it. On the remote side the class will be uninitialized. Serialized object has to be be recreated from scratch after its transmission over the network. This is why no args constructor and its setters are required here (unlike plain Java serialization). Normally you find the necessity to have , default constructor at runtime: Exception is thrown on attempt to create an object on the other side. And it could be easily fixed by creating this default constructor. And it's not obvious that you have to create setters as well. As a result the object won't contain the transmitted data and it is difficult to find a reason why it happens. All these hidden cases (and a bit more) are being revealed by the editor assistant when you use RPC interface methods.

Using editor assistant to create a connector class

In the main article server side component and its connector have been created via the wizard. Several steps are required to do this: one have to call the wizard, set its name and location, select a supecrlass. Using the wizard could be avoided if you want to develop iteratively. You could realize at some point that existing component functionality should be extended. In order to do this you subclass the component and write the code inside. After a while it turns out that existing client side functionality of the component is not enough for your purpose. So you would like to extend client side code as well. Instead of wizard or manual connector class creation from scratch the editor assistant could be used here . The wizard is not appropriate at all here because there is already component class. Many mistakes could be made on the way of manual connector class creation (see main article). In order to use editor assistant just select a server component class as a context in the editor (put cursor inside class declaration f.e. on it's name). Editor assistant detects the connector class absence and suggests to fix it. The only action you have to do here is give a name to the connector class (along with widget name depending on chosen fix). All the rest of routine work will done by the assistant.

Hints for AcceptCriterion classes

Vaadin framework has DnD capabilities. Custom AcceptCriterion subclass could be required for your purposes in order to implement DnD based functionality. It's easy to forget that the server side class requires a client side class pair. The editor assistant shows a hint and suggest a fix, which can be used to generate client-side class with the correct code for such a case.

Creating and using Themes

Vaadin application uses resource files located inside the web application directory for styling. The collection of such files in a specific directory is called theme and it can be set for the application using @Theme annotation.
Editor shows the hint if the annotation is missed. The fix for this hint adds annotation and generates theme directory with all necessary files.