Hi, See reaction inline.
> 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. Such sites are often relatively simple UI-wise, and bookmarkability and indexing for searching are important considerations (like you stated). Wicket might be not the best choice for these kinds of sites. If you use WIcket for them, you have to plan well, using bookmarkable pages/ links and other Wicket tricks. Amongst Wicket's strong points is that it scales very well for development (due to the fact that you can develop self contained components and use static typing for instance), and that it makes developing complex UIs relatively easy. If you don't have to deal with complex UIs/ large diverse teams etc/ Wicket might actually be overkill and even in your way. Do note however, that you would likely replace one hassle (in your case planning for bookmarkability/ session continuation) with others when using other frameworks (like security concerns for instance). > 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. Yeah, such are the sites that I typically had to develop (and still) during my career. Rather than focussing on whether sessions should be resumed automatically etc, often a more interesting question is how complex your UI is. Search and e-commerce sites are fairly simple UI wise. Things get more interesting - and often very difficult to implement elegantly with other frameworks - when you incorporate tabs, wizards, pageable lists etc. > Some of them > remember where you wanted to go and redirect after you re-login. That's easy to achieve with Wicket. > 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. Yeah, our Ajax implementation is in the way of statelessness. You could develop something from scratch, where the Ajax part is not based on behaviors. > 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. I would be in favor of having stateless Ajax somehow, at some point. Not easy though. Wicket is already 10 times more complex than most of us would like, and facilitating more corner cases (which I mean respectfully btw) will make it even more complex. > 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. But here is the thing... Most competing frameworks will work OK for building sites like Google and Amazon etc. Is brilliant as some of these implementations are I'm sure, the interesting stuff in such sites happens in the back-end, not so much the UI. Before I stumbled on Wicket, I was looking for a framework that would help us scale our development effort, and that would let us develop web *applications* with complex user interfaces without having to resort to a big bag of hacks (typically ad-hoc session usage) and ending up with code that is very hard to maintain. What I'm saying is that Wicket was *not* designed for Google and Amazon like sites. If you browse the archives of this list, and even maybe an interview here and there, you can see that we regularly stated this in the past. > 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. Yeah, that's all nice in itself. But a stateful programming model has been the basis of Wicket from the start. Jonathan wanted to have an OO programming model to develop web applications, and OO is stateful by definition. > 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? I don't think that would go anywhere. Extending session timeouts is not a real solution by itself. > 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). A much better way of solving your problems is to work with plenty of bookmarkable pages AND use cookies to recognize that you could pick up a session again, and you could even for instance save the last page or pages a user visited in the last visited etc (I'm sure Amazon does something like that). You'll just have to plan carefully for it, and depend more on your own brainpower than to expect everything to come from the framework. > 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. The problem that Wicket tries to solve is quite hard*, and consequently the framework has gotten quite complex. The more we facilitate corner cases and try to be a framework that fits all imaginable problems, the harder the framework will be too maintain, and - due to having more options to cover - the harder it may be to use. We've taken some serious looks at how to come up with a hybrid model and push Wicket into supporting even more stateless use cases, but so far these efforts stranded because the solutions we came up with were very hackish and would probably open up a big fat can of worms we wouldn't be able to support properly. Maybe we can improve things here and there (we're all for that!), but it is really important that people come up with intelligent solutions (patches would be great) rather than just stating shortcomings. Cheers, Eelco * I'd like to compare Wicket to Hibernate, whereas Hibernate tries to bridge the gap between OO programming and relational databases, Wicket tries to gap between OO programming and the stateless HTTP protocol and the fact that browsers are page oriented rather than widget oriented. Model 2 frameworks are way less complex because they don't aim to bridge any paradigm gap. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
