there may be places where improvements are possible, but i think the answer is not to ruin your programming model by not using sessions. i think bookmarkability is a separate issue and one that is quite nicely addressed in wicket /when you need it/.
one simple thing you can do to increase your session lifetime is to simply set a longer session expiration time in your container. i'm not personally having any problems in this area at all since 1.3 came out and i haven't heard much from anyone else about this either. i'm curious if others have issues to share. Doug Donohoe wrote: > > 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-tp16992791p16993345.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]
