I think all of us were frustrated a lot more than once during our career and decided to rant about it. I do think Eric's comments were actually made to be contradicted by the experienced people here so that he could learn more about Wicket and so take something out of it. It showed passion for the profession. It's a shame to analyze somebody's competence based on their LinkedIn profile, no matter how you look at it. How relevant is that, really? I've seen people with tens of years of experience who couldn't properly debug code.
I for one love Wicket and might use it for any kind of webapp, but it's by no means a silver bullet. Anyway, reality proved that most times it was my dumb programming that made the application not scale or use too much memory, etc, not the Wicket framework. More I learned about it, which was most times by browsing the CODE itself, not the books, not the documentation...., the more I knew how great of a framework it is. I do love writing the SQLs myself or the html or pluging some nice JQuery, but also letting my designer do his own thing (and appreciate a good DBA), no matter how much I believe in my own skills and basically Wicket was the first framework that I found to allow me to do just that. Then again, I'm the only one I know who really appreciated Swing development, which comes close to the Wicket way, so I'm sure there are plenty who think Wicket sucks. It's their choice to do so, even it they say it to my face, in my home and even not so politely :) On Sat, Nov 19, 2011 at 8:24 PM, Jeremy Thomerson <jer...@wickettraining.com > wrote: > 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* >
