Hi Jonathan, I'd like to open a discussion about this stance on "stateless" web ui because I think the original question is really one about Wicket's use of the session. By default, all wicket forms and links are stateful or dependent on the Wicket Session. If the session goes away, the links and forms cease to work. This can lead to a bad user experience.
For example, in trying to figure out how to do paging, I was using the Wicket repeater view examples application: http://wicketstuff.org/wicket13/repeater/. I must have experienced 'page expired' messages 5 times because I'd look at an example's source code, work on some code, go back to learn some more only to lose my place and have to start all over again. That was frustrating and unnecessary. Perhaps this is just bad application design - they could have used bookmarkable pages - but they used the default wicket way. You stated "i personally think 'stateless' web ui is nearly always a fantasy or an architectural mistake." It seems to me there are two classes of applications: * Primarily stateless (or in Wicket parlance, primarily bookmarkable) * Primarily stateful Stateless Sites ----------------- For example, Google's search is apparently stateless. I can bookmark any search result, go away for hours, days or weeks and re-visit the link without experiencing a session-expired message. I shop at Amazon quite a bit. I can have a page open to a product for hours and no matter when I click "buy now", it always works. My Yahoo page is similar. I use several computers and I may have a My Yahoo page open from days ago. If I click on any link, or submit a form (e.g., weather / stock), it always works. So, in many common sites, they appear to be stateless. Some of these cites certainly maintain some state on the back-end, but it is transparent to the user. Stateful Sites --------------- Examples of sites which are legitimately stateful and require you to start over when the session expires are banking and finance sites. If you leave a page open for a while and go back to click on a link, you often get "your login timed out" and you have to login again and start over. Some of them remember where you wanted to go and redirect after you re-login. Wicket -------- My experience comes from moving http://online.ddpoker.com/ from jsp to wicket. I'm about 75% done. Other than normal learning curve time, it feels like I've been spending too much time fighting the session expiration consequences. My goal (as is most, I would guess) is to create a site that has a good user experience. I don't want a user to ever see a "page expired message". That is bad application design. I want my architecture to help me avoid bad design. One example was figuring out how to create a bookmarkable form submission (I captured my experience on my wiki: http://tinyurl.com/6xhyl3 ). Another example is trying to get my login form to not expire. However, since I unveil it via Ajax, it seems to not want to be stateless ... haven't investigated it much, but I'll probably have to create some workaround. My point is that wicket should make things easier. These seem like very common issues - I'm curious to hear other users perspectives and experiences. If I were on the wicket team, I'd ask the question: How could one use Wicket to rebuild sites like Google, Amazon.com, My Yahoo, etc.? Developers are looking to choose a framework to build cool applications. There are a lot of choices out there. I chose to use Wicket over other frameworks like Ruby on Rails because I fundamentally like the approach of 100% Java and very little specialized markup. Being able to refactor, find usages and leverage IDE support is a huge win. Moving Forward ------------------ So, to further expand the original question regarding plans for the future of Wicket, let me add these thoughts: It seems like there are multiple approaches to address the Session Expiration issue. One is to make sessions that never expire. Keeping a session alive for-ever in memory is obviously not a feasible approach. However, perhaps sessions could be spooled to disk after some time. Has there been any work done on this? Another approach is to provide a more graceful session-expiration strategy. In many cases, you could redisplay the original page (perhaps there are cases where the no-arg constructor would work). Finally, there are likely cases where parts of a page could be stateful and others stateless. In my case, even though I display a login form via Ajax, it still should be possible to submit it in a stateless format. Let me end by saying that I am a big believer in the framework. However, I feel the session expiration issue is a stumbling block. I welcome others perspectives on this. Respectfully, -Doug Jonathan Locke wrote: > > > there will be no wicket 2.0 (no breaking changes). wicket 1.4 and 1.5 are > next. > > wicket already provides a good amount of support for statelessness in 1.3 > and it seems unlikely it will provide much more than it does now. > > i personally think "stateless" web ui is nearly always a fantasy or an > architectural mistake. > > > bhitai wrote: >> >> Hi all, >> First of all, I feel that this forum is great, and the technology being >> developed by the Wicket folks is simply amazing. I am trying to pitch >> Wicket to my organization that has a Spring mvc implementation in place >> (yet the web 2.0 requirements are far beyond what it can handle - hence >> the need for re-investigation). The insistence of Spring designers on >> stateless-ness has made this idea of transitioning to a session-heavy >> framework a rather tough one. I'm therefore curious to know about the >> timeline for Wicket 2.0, which I believe will support stateless >> components? Can you guys suggest some interim strategies (mitigating >> factors) in the meanwhile? >> >> thanks >> jaf >> >> > > -- View this message in context: http://www.nabble.com/Wiket-2.0-time-frame-tp16992791p16993290.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
