Could somebody explain to me the most often used reason for sometimes needing to extend the client side GWT components, in addition to just extending the server-side Vaadin objects?
I think this has to do with my lack of understanding of the specifics of client-side and server-side, but the only time I ever had to implement something on the client-side was when I needed to add a custom listener to a component.
Basically , what I am asking in a bit of round-about way is if a designer wants to implement some functions on the client side only that would not require any communication with the server, do they only need to do this by extending the GWT components?. Actually, I feel like this is often done for things like animation (RatingStars component for example) since it only needs to be visible on the client side, but I do not fully understand how this is usually done for simple GWT<->Vaadin interface components.
Are all simple GWT components implemented in the user’s browser already, and the server-side code is just telling the browser how to “paint” them? I mean is GWT just a way of transposing code into pure javascript using some custom GWT Java libraries? If so, is GWT mostly a client-side framework, as opposed to Vaadin which has most of its logic implemented on the server-side and only uses GWT for the client-side?
The reason I am asking is because I often find myself creating panels that have a button that allows the users to show/hide content. Usually I do it with a button that changes the IsVisible() variable, but I am just wondering if there isn’t a way to do this strictly on the client-side with javascript without the server needing to respond every time the user clicks on the button.
What pure GWT does is that it converts all your java code into javascript that can be shown in the browser. What Vaadin does is it creates readymade widgets with GWT and then has a server counterpart that instructs the client side on how it should be painted and behave. The server side doesn’t say in any way what the component should look like, it just contains the state of the component. What is great with this approach is that you can build up applications without recompiling the javascript all the time - you just instruct the server side component and the precompiled client side code will take care that it looks the way you want. Another benefit is that you have no business logic code inside the browser. Another benefit is that every action the user takes produces just a message about it to the server, like the user pressed button x, or the user entered the text ‘abc’ in textfield y, instead of calling a specific method. A downside is that it has to visit the server on every action the user takes.
A case like your isVisible() -toggling button is something I would definitely handle on the server side, as you have all the capabilities there. The cases when I go modify the client side, which is quite rare, is when there is no ready made widgets that can take care of my use cases, like adding a listener as you said. I might consider implementing something in the client side as well if the component I’m looking for is very roundtrip -heavy.
The communication between the server and client is quite simple. The server has one method to send all the variables to the client side and one method to get responses from the client, and the client side has one method to receive all the variables from the server. You can basically convert any GWT widget into a Vaadin widget by implementing a one-method-interface in it, and implementing a server counterpart to it.
Not sure if I answered your questions, but I’ll try to answer them if you have anything more to ask.
Drawer is a (partly client side) add-on component that does something like this, but you are probably also fine with simpler server side logic for this as long as you don’t need animations etc.
The
PortalLayout also has ability to hide the contents of the Portlets (among other fancy features). Though it notifies the server on portlet collapse, it is a really small server update and shouldn’t be a problem at all.
Actually Alex, I am modeling this view toggling exactly on your PortalLayout so it’s good that you mentioned it. I have tried to implement your add-on but for some reason, even though the component gets compiled correctly in Netbeans, the browser keeps giving the ‘widget implementation missing on the client-side’ error. It works in Eclipse, and all other add-ons, like the RatingStars add-on for example are compiling fine and are visible when I compile my widgetset in Netbeans, but for some reason I could not get the PortalLayout to work. I only needed certain parts of your portal interface framework, which from the online demo seems very,very good, so I decided to try to rebuild a few components on my end.
Mainly, I decided to basically follow your concept for creating a collapsable panel (simple abstract class extending vaadin.ui.Panel with close and min/max buttons, i.e. something like the PortletHeader mainly), and I noticed that you extend the GWT ComplexPanel class for the client side for PortletHeader, and you implement a lot of variables and methods there (for example setClosable()) and I have not been really able to understand why you also decided to have them on the client side. Is there a specific reason or could one just get away with only implementing some of the logic only on the server side?
If I have one more question, if someone implements anything on the server-side, what happens to the application state when the communication link fails like when user loses connection? Things implemented in javascript can be made to run locally, so certain things do not need to check for server link, and they only need to be loaded once by the browser. Does one need to implement methods strictly on the client side to allow a behavior like that?
Simplest case: let’s say I want to implement a Vaadin button such that whenever it is clicked it changes its own caption to a random number between 1 and 10. However, I do not care about its state on the server side (it makes no difference what the number is, or if or how many times the button is clicked etc.). Can I just extend the VButton.class and implement the method there, such that the button state is only changed on the client-side and it only needs to be loaded once on the client-side and then the user can click it however many times they want even if the server connection fails? Then on the server-side I would just need to create a button component using the new VButton widget and add it to a layout?
I understand that making things like this is not always the best idea, however let’s say a user has to add a product and uses a form that has a lot of fields. If the link fails while they are working on the form, all the fields will be reset and I was thinking that maybe certain things, like validation for example, could be implemented to run locally, using javascript, while still allowing them to have isImmediate()=true.
Also, You mentioned that you normally would try to only implement something that needs to make a lot of round-way trips on the client side. Could you give me an example of what a typical thing like that could be?
That’s a bummer you have problems with PortalLayout and NetBeans - I will investigate the problem on the weekend and if you’re still interested - will report of the results (some pending small issues have to be resolved as well). Regarding the amount of the methods on the client side - it is just how i like to program. Let the thing to be a bit more verbose than it could be. Sure - you could have server side only interface and update all the sizes and DOM inside a single updateFromUidl() method. But that would, firstly, make the code unreadable and, secondly, will prevent you from separating a working GWT widget (that’d function without Vaadin at all).