the examples app are just bad example because there the session expiration is 5 minutes or something like that
You can up the session expiration to 24 hours or something like that then it wont happen at all If you want or use ajax and wicket then you can forget about being stateless because that will make things statefull no matter what you try. Google search is just 1 stateless forms, with other stuff google pushes a lot of state to the browser itself. If you dont want to up the expiration timeout to 24 hours then just throw in a ajax poll behavior on your pages So that as long as the user have the page open in the browser then it will never expire. johan On Thu, May 1, 2008 at 5:02 PM, Doug Donohoe <[EMAIL PROTECTED]> 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-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] > >
