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. 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. 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. Again, if I am correct, then the struts/mvc approach typically is keep as little in memory across requests, but each request may need to spend some processing time loading up data to reconstruct a page to send back as a response (or set as attributes for a JSP page to use to render the response with). So there is a bit more processing and temporary memory use, but the memory expands/contracts continuously as users make requests and responses go back. At least as far as I understand the whole scalability side of things, this is better for more user capacity. As for session replication, at least in the old days, you had to replicate session data to at least one other server in the cluster. In Wicket, how is this done? Another area I am not keen with at all with wicket which is mentioned is having to build the object tree code the same way the html page is. With element Ids, I am a little confused as to why we cant simply insert the component using the element id and let wicket figure out where to stick it on the page. To me, as it scans the html page for wicket ids, it should be able to pluck wicket component/objects from a Map using the same ID and put it where it needs to be. This is one of the areas I have had some trouble getting right. If Wicket did not have this requirement, you could rearrange panels, components, etc on a page and not have to worry about any server side code change, redeploy, etc. It would, in my opinion "fix" Wicket as the ultimate framework (barring my question about scalability/session memory above also being resolved). Someone mentioned Wicket 6 will resolve something of this.. if you could elaborate (or point a link) that would be great. I would love to see them resolve this issue in the framework. It would be great to allow a web page designer build up the page, then I add dynamic elements, then they decide to change things around and simply edit the page and redeploy and see the changes, then do it again until they like it. Lastly, the bookmarkable and ugly link stuff.. I also agree that it's a bit of a pain. It may make sense to some, but having to worry about bookmarkable links and when to use them or not, etc adds to the complexity and learning curve. I think this is one other area I enjoy about Struts, but perhaps I've not worked enough with Wicket to fully realize why its needed and/or can't just be avoided. Otherwise, I love the idea of Wicket. I've often thought of making my own template framework like how I describe above.. stateless on the server side (no object model in memory), modular components that can be reused on any page, without all the JSP scriplet nightmares. Look forward to any replies. Thanks all. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4087666.html Sent from the Users forum mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
