Sorry, I don't have time to read your whole message right now (man these are some long messages, huh?), but I scanned it and saw a couple things I could help you with right away.
On Sat, Nov 19, 2011 at 7:52 PM, jlazeraski <supreme_java_gur...@yahoo.com>wrote: > Hey all, > > Wanted to weigh in on the subject as I have some similar feelings regarding > Wicket and since so many experienced have posted perhaps they can be > addressed. > > I will however include some positives. I absolutely love the idea of the > templated html page where by a web designer can build up the page and I can > focus on the back end code that adds the dynamic content. I did buy WIA and > another, Wicket Cookbook I think it is, and while I read and understand the > principals behind the framework, it was indeed a much steeper learning > curve > for me. So much so that even after reading the book and starting on my own > project, I had a difficult time getting basic stuff working. However, I'd > still like to learn it more and use it for the separation it provides > between the back end and the web page itself. > > I also love the idea of panels. My go to framework is (don't hate me for > it) > Struts 2 and/or Jersey (via ajax calls to a rest api). I have found that I > love the idea of annotated classes to handle actions, response strings that > forward to specific jsp pages and all the code I can do.. calling to ejb > session beans, etc. The biggest down side to using Struts is, as many said, > the JSP hell. JSP itself is not too bad.. but when you add in <% %> code, > scriplets, looping constructs.. it's a darn pain in the butt to manage. > This > is why Wicket appealed to me so much. Also, getting back to panels, the > notion of reusable components that you just place an element in the html > page and put the component in the tree in code and it "works" is > fantastic!! > Those two things are why I will attempt to use Wicket in the near future > soon as the project I am working on is out in beta and I can look to switch > from Struts 2 to Wicket. > > Now for the areas I am not so sure about and hope maybe some of you may > have > some answers for. > > The big one for me is the server side statefulness. Maybe I misunderstood > this, but I am really worried about the ability for Wicket to scale given > that it keeps per user object trees in memory for the page the user is on. > On the one hand, that is pretty nifty especially for the swing like event > driven approach with ajax, but where I am not sure of is with the memory > consumption used continuously on a server, it seems to me you would reduce > the number of users per server you could handle. A lot of people have this same concern when coming to Wicket. However, this amounts to the equivalent of "premature optimization" - assuming that something will be your hotspot when it will not be. I recently wrote an article for an in-print Java magazine about Wicket (I'll post more details to the list soon). Here is an excerpt from it. Please read the two included links: QUOTE: "If you’re really concerned about being able to validate my assertion that Wicket will not use more memory than other frameworks, you may want to check out http://tinyurl.com/wicket-perf-1 and for a more elaborate comparison of Wicket versus several alternative frameworks, see http://tinyurl.com/wicket-perf-2 (both written by Peter Thomas)." Put simply: use Wicket correctly and it does not take up more memory, and in fact less, than other frameworks. > More so, replication of > state information would require 2 (or more) servers in a cluster to have > the > same sort of object tree + state in memory to have any sort of fault > tolerance. Don't you always need more than one server for fault tolerance? I don't see a difference here. Maybe I don't understand what you're saying. > Am I correct in understanding how Wicket maintains an object tree > per user on the server side? If this is the correct understanding then to > me > the stateless model of using a REST api or Struts actions where each > request > comes in with a session id, and minimal data is in the session.. typically > just a userId tied to the sesion id so data can then be looked up using the > userId. You can do the same thing in Wicket. The component hierarchy itself is *extremely* light on memory usage. The component hierarchy is *never* the problem in a memory leaking Wicket app. It's *always* what people decide to store in their components, or even more often what they didn't realize they were storing in their components or models because they don't understand how to use them. * Caveat: I've seen the component hierarchy actually be a memory-hog once. A client had a page with a ListView that showed several *thousand* products on one page. For each row there were over a dozen components. Obviously, that was not a good way to design things (from a programming or user interface perspective). Sorry, that's all I have time for right now, but I'm sure others will help address your later points. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
