So one will save a lot of lines and local variables when method chaining is available. (I know there is setSize(x,y) just for illustration).
There are a lot of those changes for usefull method chaining burried. The superclasses can use Generics for the actual type being returned.
method chaining will not be in Vaadin 7 as there is too weak support for it in Java 6 to make it work nicely. The largest problems comes from the class hierarchy and the fact that when running a method on e.g. a Button you would expect a Button to be returned. As e.g. setWidth() is defined in AbstractComponent you would either
a) get an AbstractComponent back from setWidth, which is really strange as the order of the setters then matter.
b) you would have to override each and every method in every component to change the return type. This is not really feasible
c) you could use generics for the return type but extending a component would not work unless you would always do new Button (if Button extends AbstractComponent then MyButton.setWidth would still return Button and not a MyButton).
Yes that is true but it would solve the 80 to 90% rule. I would use the third. One would rarely extend a core widget and expect to set it up this way. And think about it if you write a complex component one would use CustomComponent. So it only does not work for extensions of the Button Table etc class. Usually I extend them only for anonymous use (classes) if ever.
I am currently not a Vaadin expert yet (just a beginner) but from my expectation I wont expect to extend a table myself but rather building something around it. But I am used to SWT and GWT here and maybe this is not the intended Vaadin way.
A third option is to make often extended classes also abstract and provide something like AbstractTable and a small Table so one would extend AbstractTable instead of Table to extend it. Often this plays out more nicely. Anyhow I just wondered. Most of my lines in the init methods relate to Component x = new …, set properties…, add listeners, add it to component so I usually end up with five lines which would provide a better read when everything is chained together in the very same pattern like. parent.add(new Button(text).setDescription(Messages.tooltip(xyz)));
It improves readability and adds to the design phase where things are often mixed and changed.
So please reconsider this. It wont break the API if the default components would support it. And also the layout would be more easily. Like component.setContent(new MainLayout().setSizeFull());. I bearly can think of a scenario where one would expect to extend the table object and would reach the setters or getters using method chaining. Usually extending something more complex means that there is often some more complex setup going on and the typical component setup is still provided by the normal table object.
Unlike in the SWT world where that is in practice not possible, I would say it is a common (even though underused) practice to extend Vaadin components for project-specific customization and for extended (usually only server-side) functionality the project finds useful.
I know some projects even subclass every Vaadin component in the beginning and only use those subclasses to make it easier to customize them later in the project. The customizations can vary from visual appearance to extended functionality to fixing bugs before they are fixed in Vaadin itself.
As for Vaadin 7, even if we would want to implement this, we are in the beta phase and I would say it is too late for such a major change that is not in our plans.
Note that the
Scaladin add-on for Vaadin does add quite a bit of such chaining support when programming in Scala.
Adding method chaining for void methods wont break the API. Its all server side related (as far as I understood it). But anyhow, I just wondered. Would have made daily life more easily. But as I understood I am also unable to subclass any component and introduce method chaining myself which I can’t unless I introduce methods with different names and signature.
So the only idea is using a static factory method comparable to:
newButton(“Button”).description(“description”).width(“100%”).addTo(component);
or addTo(component).newButton(“Button”).description(“description”).width(“100%”);
Well so its all right its only an hour to ease setup this way and it can be easily extended. I also saw the amount of work you are facing. So dont bother with this unless you also felt that its a good add.