The last couple of weeks I have touting a proof of concept at work showing a client side implementation of the Table component that speeds up data entry by implementing on the client side a lot of functionality that we were implementing on the server side via value change and focus listeners. My client side implementation is written in Vaadin 7.0.4, and extends the VScrollTable, VScrollTableBody, and VScrollTableRow classes.
In
today’s blog post
, Leif mentioned a “rewrite” of the Table components.
Because Vaadin is a server side API, my immediate concern is whether the VScrollTable and it’s inner classes will still be available after this rewrite, or if it’s going to be completely removed, or if the rewrite will be the same class name but it’s going to be rewritten or refactored to the point that any extensions of it will likewise need to be rewritten or refactored?
However, making my question more relevant to a broader audience (and yes, trying to find an excuse to pressure you into feeling you need to provided a deprecated support to the VScrollTable for at least a couple versions after 7.2.0 is released), since Vaadin touts the ability for users to write their own client side components, frequently by extending Vaadin’s client side components, I’m wondering if Vaadin’s client side API is also considered a contract. As Vaadin periodically rewrites any of these components, has their been or is there any plan to provide any backwards compatibility for any of it’s changed client side APIs through out the version 7 life cycle?
Thanks in advance for the response, this will have a pretty large impact on how we go forward with our client side implementation, and possibly other client side implementations in the future.
The old Table will stick around for the time being, deprecated and possibly renamed (or moved into a legacy package). The new table, whatever it will look like in the end, will be a separate component with a separate client-side implementation.