On 10/11/06, craigdd <[EMAIL PROTECTED]> wrote:
I've read a couple times that with wicket 2.0 a feature has been added to allow developers to define if a Page is stateless or stateful. This feature is pretty nice and gets wicket a step closer to some of the features that JSF has and greately decreaes the size of the session in a large application.
What I know and heard from JSF is that they pretty inefficient in their memory use. Wicket tries to minimize stored state by only keeping the deltas of changed pages, making use of detachable models, and putting a limit on what it keeps in the session. And with Wicket 2.0 by default only the current page is kept in direct storage (session/ mem), while older pages (for back button support) are written to second level storage (fs/ db). So on the server side, I'm sure we're already a lot more efficient than JSF. Now the commonly used pattern to serialize state to the client... We've discussed that a lot in the past. While it sounds like it is good for scalability, it is not necessarily so. For longer term memory consumption it is, though you'll have more peaks because of serialization/ deserialization, but the CPU load will be much higher, and it will use much more bandwidth, especially with the kind of brute force serialization that is employed by frameworks like JSF and .NET. I have actually *seen* pages of over an MB with .NET. Imagine putting that over the line, and serializing/ deserializing it. The morale: go find a book store and read Freak Economics. The assumptions you make with common sense, might turn out quite different :)
With that said, has anyone gone a step further and though about have Page scoped somewhere between stateless and stateful? The basic concept would be the page is stateful as long as it is need and when not needed it is removed from the session.
We've discussed such an idea a long time ago, but decided against it. If you really want, you can implement your own IPageMapEvictionStrategy, keep references to pages in other pages or maybe even in your session. But basically, fat chance that you don't even need such a page by setting things up slightly differently.
I have really thought about how this would be implemented but maybe for starters it is as simple as have a limit on the size of Pages in the session, when the limit has been retched then the oldest request Page is removed. Just a thought, it might be a winning featuer that JSF doesn't have.
The real winning feature - imho - of Wicket is 'just Java programming'. Plain stateful objects. Clean templates. :) Eelco
