I'm using Wicket 1.3.3 on Tomcat 6.0.16. I'm using whatever the default session store implementation is because I haven't done anything to configure it.
Are you suggesting there is a way to avoid session expirations? I'm not sure your previous suggestion to lengthen session time-out solves the issue because (a) it basically delays the problem and (b) causes the server to use more memory than perhaps is necessary. My experience with the wicket-stuff at http://wicketstuff.org/wicket13/repeater/ suggests that this is an issue. I couldn't step away from a source-code example for more than 10/15 minutes without having the pages expire, at which point I had to find my way back to the right source file. I can't link to the source page since it wicket:interface style link (the one at the top of the page). Rightly or wrongly, as a first time user, what sticks in my mind is an awful lot of "page expired" messages. I'm pretty sure I saw them very early on when exploring the examples off the main wicket.apache.org page. I think this is all hosted life at wicketstuff.org. Is that server configured improperly too? Cheers, -Doug Jonathan Locke wrote: > > > the more i think about this, the more i'm suspecting you've just got a > bunch of configuration problems. > > what version of wicket are you using and what session store > implementation? > > also, tomcat provides a facility for writing out less active sessions to > disk. > > > 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-tp16992791p16994426.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]
