> I'm still not completely clear of what "server-side state management" means,
First and foremost, the reason for Wicket managing the state of components transparently is that it aims to provide it's users with a true object oriented programming model. Remember that objects are data + behavior. Isn't it crazy that a large part of the developer community uses Java to develop web applications in a procedural fashion? I think it is. What this buys you besides having a programming model that doesn't suck? That depends on the situation. Take for example this sketch of a component that is used in the day project I'm working on. ------------------------------------------------- | [switch to normal editor] | | ------------------------------------------- | | | | | | | | | | | | | | ------------------------------------------- | ------------------------------------------------- It is a text editor with a link that will switch between rich editing and a plain text area. Simple as it sounds, creating such a component is not trivial in most frameworks; you either have to carry it's state (what mode it is in) over in all the URLs that can have an effect on the page, including URLs that take you to intermediate pages (when you work with tabs are are in a wizard for instance), or you have to keep it in the session object. The latter is what programmers typically use (in my experience, and for a good reason, as carrying URL parameters over is pure maintenance hell), though this has the disadvantage that such ad-hoc session usage leaks all over the place. Programmers forget or can't know when to clean up, and on a larger application, there may be tons of instances of such ad-hoc session usage. Alternatively people start telling their customers certain funcationality can't be done or only at a great price or with a different technology (like flash). But now, with Wicket, creating such a component is super easy. Going from there, there are actually quite a lot of components that benefit from the ability of keeping state. Think about paginated lists, trees, tab panels, wizards, etc, etc. Such components can be created with other frameworks usually with quite a lot of pain and/ or limitations, but with Wicket it is easy. And the main reason why it is easy is because it is a stateful framework. But it doesn't stop with simply reusable components. Once you get the hang of it, you'll find that creating complex navigation structures (more opinionated ranting here: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/) and dependencies between components (such as e.g. the breadcrumps component employs) are relatively easy to implement largely because of the ability to use state in your components. > but seeing as Wicket is built on the standard technology, I assume this > means using HttpSession to store information. By default, Wicket stores: 1) The user session 2) PageMaps, which contain the current page for call backs (links, forms, etc) and and a number of pages for back button support. Where exactly that info is stored depends on the ISessionStore implementation. In Wicket 1.3 (our default), the default implementation uses a HttpSession instance to store the use session and current page, and it saves (using serialization) older pages to a second level cache (temp dir by default) for back button support. All as much optimized and non-blocking as we could get away with :) > Things being Serializable > seems to be a common technique within Wicket; does this mean that the > HttpSession will become full of serialized objects? How can this not affect > memory usage? Or is this the trade-off, that is, if you use a > component-based framework, you don't have to worry about the session state > so much, but you better add more memory to the production box(?). Yep, that's it. It's a trade off. If memory is a prime concern, Wicket may not be your best choice. But I think that in general, the programming model is well worth the price, especially considering for most applications, the larger share of costs is in development hours, and then specially those spent for maintaining the application. But if you are developing the next Google, this may not be the case of course. Best thing for anyone to do is look at the pros and cons and try to do your calculations. Remember that the root of all evil in our business is premature optimization. :) Hope this helped, Eelco ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
