Ant way to lock refresh and back buttons in V7?

Migrating to Vaadin 7 I noticed the UI.init method is called whenever the user refresh browser window, but I also perceives that a fully new UI is created. As a result, whenever the user hits the refresh button, all its state, including login will be lost.

I agree that in an Ajax application the user shall not use the refresh button, but in practice new users will do that. Same considerations apply to the back button.

Note: I tried the view + fragment method in Vaadin 6, but in practice has a lot of side effects, for example going back to a page whose associated entities were deleted. Absolutely the same would happen with non-ajax applications: the browser will show a cached page associated to outdated resources. The truth is that the back button only makes sense for content browsing applications.

My question is: how other Vaadin users manage this? Is there any way to lock those buttons? Is there a way in the UI.init() method to recognize the session was already active and skip initialization (in vaadin 6 I did that - poorly - through URI handlers. I am unable to do the same with Request Handlers). Or you simply explain user by user that they shall never touch the refresh button?

In a word, no!

However, you can change the the recreate-ui-and-state-on-refresh by using the @PreserveOnRefresh annotation on the UI class; see
this Wiki



Also want to add, if you make use of the Navigator and Vaadin 7 Views the user can use the browser back and forward buttons to navigate between previous Views (Unlike Vaadin 6 where this would usually have swapped out of your application).

This is one of the main reasons to upgrade to Vaadin 7 as far as I’m concerned.

Hi Charles,

Many thanks! That’s exactly what I needed. I’m gonna try it.


Hi Petrus,

I implemented the back button as described already in V6, and I shall say that it works fine (no swap out). Obviously in V7 will be easier. But there is a fundamental issue that has nothing to see with Vaadin or Ajax and any web application is subject to this problem. Going back the user can go over a view that does not make sense any more. Suppose user deletes a record and then goes back to it, any action will be illegal and possibly throw null pointer exceptions. Each view shall take care to be in an illegal state because the user reached it through the back button.

I am still implementing the back functionality in the V7 port, but I will leave enabling optional. My main reason to migrate to V7 is that the application is still not in use and the architecture of V7 is quite superior, thus I decided to migrate before entering the maintenance phase.



Perhaps not quite the solution you want, but if you use the Navigator and Views you could intercept the view change, this way you should be able to stop the navigation change for the “Back” button. ( Have not tested though )…

Interface com.vaadin.navigator.ViewChangeListener
    boolean beforeViewChange(ViewChangeListener.ViewChangeEvent event)

    Invoked before the view is changed.
    This method may e.g. open a "save" dialog or question about the change, which may re-initiate the navigation operation after user action.
    If this listener does not want to block the view change (e.g. does not know the view in question), it should return true. If any listener returns false, the view change is not allowed and afterViewChange() methods are not called.

        event - view change event 
        true if the view change should be allowed or this listener does not care about the view change, false to block the change

↑ It’s right.