IMHO whether state at the client helps hugely depends on the amount of
pages the user works with.
If the user hardly ever leaves that one single page, keeping state on
the client will help performance, provided the server does not need to
keep a copy of (all) that state. The latter deviates from the main
Wicket philosophy as I perceive it, but it is certainly possible in a
clean way. (In my current project we do this in a few places *.) If you
want to go this way, you'd better have a very Javascript capable person
in the team.
If your user is constantly requesting quite different pages, the Wicket
model is probably a better match (possibly using stateless pages
wherever possible).
Regards,
Erik.
* Before you ask: we use JQuery to get content from a URL which maps to
a stateless Wicket page that serves HTML fragments. For more simple
things (e.g. validate an access code) we use a couple of servlets.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
