Your feedback to the alpha and beta releases of Vaadin 7 shows that you are appreciating the headline features, e.g. UI, Navigator and the new communication mechanisms. There are however some question marks surrounding some of the smaller changes we have made. I want to take this opportunity to explain to you why certain things that you did with Vaadin 6 can no longer be done in the same way in Vaadin 7 and what you could do instead to achieve the same results.
Dynamic Theme Selection
In Vaadin 6, you could use Window.setTheme at any time to change the theme of a Window with one caveat: The page was automatically reloaded if the Window was already displayed. This was required to eliminate any traces of the previous theme to avoid almost certain conflicts between the themes.
This slightly hacky approach was broken by two design decisions for Vaadin 7. The first change is that reloading a page in the browser will by default cause the server-side state to be reinitialized, which would destroy any data that the user had entered but that had not yet been persisted.
Second, the additional information from the browser that we now make available when UI.init is called requires one round trip to the server. To reduce the performance impact of that round trip, the theme is loaded in the background while that request is made. This means that we have to know which theme to load long before your UI.init method can tell the framework which theme to use.
We could have made various compromises to work around both issues, but we did instead choose a different route as we knew that support for using multiple themes on the same page was also on the roadmap.
The Vaadin 6 way can be emulated by adding a @Theme annotation to the UI class or using a custom UIProvider that dynamically provides the information. You should then also take care of reloading the page if it has already been loaded. This way does however require understanding some quite advanced concepts and we haven't provided any explicit documentation for how to do this yet.
Multi-theme support has since then been delayed by overly optimistic scheduling, changed priorities and circumstances out of our control, forcing us to ship beta versions without an easy, documented way of changing the theme on the fly. This should soon be rectified as we are about to finalize the changes needed to have multiple themes loaded on the same page without conflicts.
Closing an Application
In Vaadin 6, you used Application.setLogoutURL(String) in combination with Application.close() to remove server-side state and redirect the browser away from the defunct Vaadin view. The new way of doing this is to first either close the VaadinServiceSession or to invalidate the underlying HttpSession depending on how the login information has been recorded and then redirect away from the defunct UI using Page.setLocation(String). See the Handling logout tutorial for a practical example on how this works.
This scheme also enables you to do something completely different upon logout, e.g. issuing some JavaScript that just unloads Vaadin from the browser and instead displays some other dynamic content without ever doing a redirect.
There is still one more problem that is not fully resolved, although the same issue is also present in Vaadin 6: If you have multiple browser tabs open, the redirect will only happen in the tab from which the logout was initiated. Other tabs will remain open and show an "Session Expired" error the next time the user does something that triggers a round trip to the server. See #9984 to track our progress with solving that issue.
More to Come in Part 2
Hopefully my explanations and proposed new usage patterns make sense to you. If not, please tell us about it in the forum. You should also come back next week for Part 2, covering popup windows and file downloads.