Let’s continue this Vaadin-web-7 architecture discussion
Currently Interceptors are called before the page instantiation. Maybe the page wil never be instantiated.
It might be nice to have the page instance in interceptors because we may like an interceptor to do some automatic value injection in the page, for example.
Struts2 Interceptors can do that because they have access to the Action instance that is instantiated before the interceptors chain is called.
On the contrary our Vaadin Interceptor has no page instance, because:
1- it’s heavier to instantiate a Vaadin page than a light Struts2 Action, and we are not sure we’ll need the page at all (an interceptor may decide to stop the call chain).
2- Struts2 has the Action.execute() method to call at the end of the interceptor chain. We don’t have that in Vaadin. Our (non request scoped) “equivalent” is to instantiate the page (which is a VerticalLayout containing much stuff, or something similar).
A solution to have the page instance in the interceptor is to have our pages implementing a Vaadin interface. (I know, PageInterface is a bad name and it should be “Page”, it’s just avoid confusion in this post)
interface PageInterface {
Component init(); // result placed in the AppLevelWindow.
}
The navigator would:
1- Instantiate our page (i.e. new HomePage implements PageInterface)
2- Call the interceptors chain (interceptor may inject values based on annotations for example)
3- Call page.init
The disadvantage of introducing PageInterface is that pages cannot be Vaadin Components anymore (instead they contain a main component, as CustomLayouts do). It’s more intrusive. I’m not fan of it.
To summarize, we have 3 options:
A. Pages are instantiated after the interceptor chain is called. Interceptors have no access to the page instance. It’s the implemented option.
B. Pages are instantiated before the insteceptor chain is called => Interceptors have access to page instance.
B1. and they are normal Vaadin component => much of the UI building is done in the constructor => it would not benefit (at constructor time) value injections done in the interceptor called afterwards => BAD OPTION.
B2. and they implement PageInterface, and kindly put the UI building code in the init method (can we really count on programmer discipline?)
My preference order is:
A. (but we cannot inject values in page instances)
B2.
Whatever you do in Vaadin 7, you probably want think about that aspect carefully.
To add naming consistency for web people, I’d rename TransactionListener to “RequestInterceptor” (if responsible to call the next RequestInterceptor) or “RequestListener” (if as now, has start/end methods).
The current interceptor should probably be renamed NavigationInterceptor (to make people understand it’s not called for every request
John.