AddressBook issue ? show stopper found ...

Hi all,

I’m new with Vaadin with great GWT experience from the start of this technology in 2006.
I’m impressed by the Vaadin framework really !
I’m playing with the AddressBook sample project and i’ve encountered a show stopper :frowning:

Use case:

Open two browsers on http://localhost:8080/AddressBook/

from one browser edit Lisa contact and change her name by Lisa8 and save the contact.
from the other browser select lisa contact and you get the following alert


Out of syncSomething has caused us to be out of sync with the server.
Take note of any unsaved data, and click here to re-sync.

Why this occurs, how to avoid it?

This is happened with the AddressBook Vaadin sample original version.

Thank you by advance to help me to continue my proof of concept to use Vaadin instead of pure GWT as i do for now.

Best Regards

Luciano

By other browser you mean other browser window. This means that the both access the same application.

By default a vaadin application only supports one browser window / tab at time (per user). In order to support multiple windows the support must be enabled explicitly. See
http://vaadin.com/web/joonas/wiki/-/wiki/Main/Supporting%20Multible%20Tabs
. This default is unfortunate and will be changed in Vaadin 7 to “support multiple windows/tabs by default”.

Thank you really much for this answer Joonas,

Yes the problem comes when i open 2 tabs because it’s sharing the same underlying http session.

I’m doing the exercise to port the AddressBook to MuliTab as for the Calculator Sample.

This raises a question. Severals beans use the AddressBookApplication in AddressBook like SearchView , PersonList beans and what i have to pass them? the AddressBookApplication as currently or the AddressBookWindow which now contains all the logic of the application.

I’m a bit lost by what belongs to a user session (The application instance ? the Window instance?)

Thank you

Luciano

Everything in the Application is stored to the session. There should be one Window object for each tab/window that is open. Thus the resources shared between tabs should go to Application and resources specific to a tab/window should go to Window.

Thank you Joonas,

I succeed to make AddressBook work in Multi Browser Tab Environement thanks to your advices.
I’ve one Suggestion :slight_smile:

Wouldn’t be nice to Call Application class UserApplicationContext or UserApplicationSession because behind it belongs to the HTTPSession and i think it is more accurate name for this class. At least for developper knowing the underlying process behing your awesome framework! :slight_smile:

Thanks a lot.

Luciano

You are not the first one to suggest renaming of Application -class. Still I am not sure what would be so much better name that rename would make sense.

Now there is one ApplicationContext instance per session (HttpSession instance). Each ApplicationContext instance can then contain multiple Application instances. As Application class defines the behavior of the Vaadin application, Application instance quite clearly defines the state of the Vaadin application. Thus there is one Application state per session.

If we would rename Application to - say - UserApplicationContext, wouldn’t it be quite confusing when we also have ApplicationContext?

You must steer away from Application. Everyone understands Application to mean “Web Application”. Every Web developer understands “Session”. What percentage of new Vaadin developers can spell “Swing” ?

I suggest you do the same as for the transaction event / http event: hide the old name, keep the old name as a wrapper or as an alternate implementation altogether we don’t care.

I am preaching and converting the heathens to move to Vaadin, with some success (the Roo add-on is helping). But this silly stumbling block is costing way too much time in explanations and confusion.

I’m in general i’m not to much in favor for too much renaming for well established technologies. servlet , session management is now well established and understood by all developpers of this name. The really valuable part of your framework is the GWT proxy you have to render, your great lib of component, the fact there no more compilation overhead and much more!. but for example in my case i’m used and like to do mash up of technologies, mixing flex , struts (rubish technology), gwt all together and the main entry point to mash up all this stuff is the session to retrieve credentials etc and interact between all the worlds and my first reaction when i started playing with Vaadin is to found where is hidden the HttpSession and which class wraps it :slight_smile:

But i’m sure all is OK, i just need to get used with this names details

Thanks Joonas for your fast and accurate support!

Luciano

Some of the concepts in Vaadin are more abstract than they need to be, because Vaadin was designed to be agnostic to the underlying technologies. Nowadays it is just for web, but prototypes for adapting Vaadin to several other technologies has existed (for example Swing, J2ME, WAP, …). Even with web there are differences - when deploying as a portlet, underlying classes are not the same as when deploying as servlet…

I understand better now.
Thanks