On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hnew...@cobaltgroup.com> wrote: > Hello Wicket folx. > > First and foremost I want to commend you on an excellent job putting together > a truly impressive best-in-class framework. > > I'm in the process of evaluating Wicket for a large-scale ajax-heavy > enterprise application. > > I've got a business requirement that session invalidation must not be a > disruptive event (no "expired session" warning or anything similar).
if this is a hard requirement you may be best served by a client-side framework like gwt or extjs. > Some of the most obvious options: > > 1. Get rid of session requirements all together by using client-side models > instead of server side models so we don't have the session invalidation > issue. This seems to be in line with "The next version of Wicket will > support client-side models for zero-state scalability" line item on the > features page. After searching the list archives I've not seen much traction > on this front. Are there any potential designs being considered or other > resources I could use to educate myself? no, we have evaluated this option and decided not to pursue it further. the discussions are on the list if you want to search, but the agreement was that ram is cheap, disks are even cheaper, and the overhead of pushing all relevant state to the client is too high. we have built support for stateless pages, but there is no support for stateless ajax, and in order to keep a stateless page stateless you are limited to a subset of components offered by wicket which are themselves stateless. > 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back > to the target page instead of the "expired session" error page. This > approach has the drawback that the model will be reset which will cause the > page to revert to default values. Ultimately, initializing the page using > values from a cookie or some other stateful store that is not tied to the > user's session would be ideal, if possible. unless you encode the page class into every url there is no way to know what page was being accessed once the session is expired. > 3. Use an external store instead of the J2EE session (like a RDBMS) with a > data-retention policy so high the chance of a ajax request being issued > against a page which has expired is practically nil. We'd also probably need > to implement our own encoder to ensure the session id is placed on every link > to survive J2EE session invalidation. or simply set the j2ee session timeout to a high value. servlet containers these days can swap inactive sessions to disk to keep the memory overhead low. same effect and no need to deal with a database. -igor > We are most-interested in contributing any substantial work back to the > community so pointers to style guidelines or other contribution-centric > resources are greatly appreciated. > > Thank you very much. > > -- Hawk Newton > Enterprise Architect > Cobalt Group, Inc.
