that's probably because the session timeout on the container hosting that example is short.
Doug Donohoe wrote: > > 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-tp16992791p16994950.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]
