Not anything downloadable I'm afraid. But here is my current brain dump on the matter.
The most important question: what are your scalability needs? If you are creating a public facing web site with possibly *very* large fluctuations in user behavior, your scalability needs are way more important than with intranet applications. The latter kind of application typically don't have the enormous peaks and variety of usage. So even if they have tens of thousands of users (like the application that I'm currently working on will have), the load will be pretty predictable, and is something that can be planned for. Presuming scalability is an important concern, where do you expect the bottlenecks to happen? In my experience, the database/ back-end typically starts crumbling way before the web tier. And if you use a clustered environment with sticky sessions, the web tier most likely will never be a real concern. Now, if you defined the web tier as a likely bottleneck, and your scalability requirements are such that you probably have to work with a big cluster etc, it's time to talk business. Learn about the pitfalls of the frameworks you are considering and evaluate that with your situation. But now my remark about that Wicket might actually uses less server side memory than some other framework... that was primarily directed to web MVC frameworks like Struts, WW, Spring MVC, etc. Unfortunately still the leading paradigm it seems. A big pitfall for web MVC frameworks is that it is hard to program complex UIs in them. Things like wizards, multiple levels of tabs, page-able lists, search panels with detail screens etc, are very hard to do without a stateful model. So what typically happens is that programmers use session memory to store 'temporary' data, like the selected tab, the previous search command, the page of the page-able list etc. I quoted 'tempory' as that stuff typically don't gets cleaned up properly - the primary reason why an MVC based application Johan profiled some time ago actually used much more session memory than a comparable Wicket application. Worse, such ad-hoc usage is unpredictable and hard to tweak in a clustered environment. Even if you had an MVC and a Wicket application that would use exactly the same amount of memory, the Wicket application will very likely put less strain on the cluster as - due the fact that Wicket controls what goes in and out of the actual session/ cluster - Wicket will try to optimize and take care to only update when it is really needed. Alternatively, you could force your programmers to never use the session for things like that. It *is* possible to achieve the same by passing request parameters everywhere. However, for complex UIs you'll soon be bogged down by an incomprehensible stack of spaghetti. You might get into the problem that your get requests are getting too long. And using request parameters is a potential security concern. But most importantly, you have to 'flat down' everything you could otherwise componentize to a page level, and every little refactoring will be tedious, and you probably will have lots of code duplication. For anyone that actually build a couple of non-trivial web applications with MVC frameworks like Struts, I'm not telling a new story here. My point of this whole section is that even though MCV frameworks potentially scale better, changes are that in practice they don't. Not for anything moderately complex. And the prize to pay for this warm fuzzy feeling that you theoretically scale better can be pretty big. Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
