Wicket is a different approach from the JSP(Spring MVC/Struts) model but is certainly an improvement over the basic Servlets and JSPs oriented MVC.
One of the benefits is that you compile your wicket components to mostly pure Java and you have a good idea how your page will behave. Yes, Wicket does a lot of the work for you. That is good or bad depending on what your requirements are. -----Original Message----- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, November 18, 2011 1:50 PM To: users@wicket.apache.org Subject: Re: Apache Wicket is a Flawed Framework i will address some points that i dont think have been addressed yet... On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki <erickiz...@gmail.com> wrote: > Violates Dry: You must repeat the component hierarchy of your widgets > that are in HTML in Java Code for no good reason. If you move your > widget around in the html it will break the Java and you get a stack > trace if you change the nesting. You have to keep these two files > synched. A JSP file is more maintainable. At least the view code is in one > place. this will be much improved in the upcoming 6.0. this is not as trivial as saying: "oh, just let me move my components in markup anywhere" because a lot of the usecases actually depend on component hiearchy on the java side so it doesnt make sense having them out of sync. anyways, this was thoroughly discussed on the mailing list, have you bothered to search the archive before ranting? here is the link to a discussion: http://markmail.org/thread/5iczgvd42k6oeera > Not previewable: One of the supposed benefits of Wicket is a clean > template that could make pages previewable for designers. the pages are previewable to a much larger degree then they are with most other frameworks. we dont claim complete previewability i dont think, and if we do we shouldnt. wicket allows you to chunk up the ui and swap bits and pieces out at runtime, so of course it is very hard to construct a preview for a page that is composed of lots of smaller pieces, however, the pieces themselves are previewable. > First, we don't have > seperate designers at my company. im sorry > Second, it is better if the samer person does development and design. heh. personally, i dont like to spend my time thinking about which css hack i need to apply to make a div line up perfectly across all browsers. i think most developers would agree with me. im just glad i work at a company where we do have designers who do that, do it well, and most of all love doing it :) > Third, if you use extends your page will not be priviewable outside > an application server running Wicket. This supposed benefit does not > exist. yep. or if you use panels. however, you are free to add chunks outside the wicket:extend tags that add the missing body/html/head tags to make the page or panel at least somewhat previewable, which our designers do sometimes. i think "previewability" in our context should mean that the designer can open a markup file used by wicket in the tool of their liking and not feel completely lost or afraid to tweak stuff. in my company the designers do the first pass on new markup, then the developers wicketize it and write the code. once that is done the designers often go back and tweak things, and they can do so easily without breaking anything - i think thats the important bit to take away. > Violates MVC: It smashes view and controller code into the same Java file. > You have code that regulates page flow and code that changes css > attributes in the same file. Even Spring MVC had better separation of > concerns. > JSP/Servlets with Spring MVC is better. ive never understood why people want to externalize the flow of the application. it seems rather silly considering a lot of the flows are dynamic. especially once you consider panel-swapping or single-page-applications as they are often called. how do you externalize that flow? you cant. also, i do not see a semantic difference between the code that navigates and the code that tweaks css attributes. they are both about the user interface. as long as no one puts business logic into my components im ok. > Excessively verbose and complicated: What is a LoadableDetachableModel? an LDM is basically a closure. its only verbose because java is verbose when it comes to creating closures, but this will be fixed in java 8. > The learning curve for Wicket is immense. yes. for those coming from the mvc/servlets/action frameworks world it involves a complete, and i hate to use the term, "paradigm shift" in how you approach problems. you actually have to learn the OOP part of java :) people who have been coding swing, swt, gwt, or any other oop framework can pick up wicket very quickly. i think all your other points have been addressed in other emails. good luck -igor > Breaks POJOS: A real POJO does not need to implement an interface or > extend a class. Wicket forces your beans to be Serializable. This is > like using EJBs in how it forced you to implement interfaces. > > Terrible AJAX: Compared to a few lines of jQuery AJAX is excessively > complicated and verbose in Wicket. A lot of things like "AJAX" links > should not be done via "AJAX" at all. Hiding a div on the client > would simply be done with JavaScript on the client. Wicket better not > require a server request for that. You also have no JSON support and > good luck debugging any JavaScript or AJAX in Firefox. Instead you > have to use the subpar Wicket debugging. > > HTML5: No support for HTML 5 form elements unless you upgrade to > Wicket 1.5. You will get a stack trace. The upgrade to Wicket 1.5 is > painful and will break your code. Good luck getting this to work with jQuery > mobile. > > Bad Defaults: Most pages are stateless. The default for Wicket is > stateful. So if I want a decent URL and a bookmarkable page I have to > mount the page and use a bookmarkable page link with page parameters. > Using page parameters is worse than how Spring MVC does binding. I > have to keep doing this over and over for each page. There is too > much work involved to get a decent stateless page with a nice URL. This > should be the default. > > Interferes with other libraries: It screws up your jQuery code. It > forces you into a restrictive way of doing web-development: the Wicket Way. > > Causes a redeploy whenever you add anything: Maybe Java developers > are used to this, but in any other web development environment I do > not need to redeploy after adding a text box to the page. It is completely > absurd. > Only with JRebel is this alleviated. No, embedded Jetty in debug mode > still slow. Even a simple JSP file has hot reloading on Tomcat and if > I make a change to my view code the changes are immediately viewable > in the browser when I refresh. This is WITHOUT JRebel. > > HTTPSession Objects are not hard: Most pages do not need state. If > you do use HTTPSession it is simple. Can you use a map? Then you can > use HTTPSession. This is less comlicated than most Wicket code. > > Stateful Component based framework are a terrible idea: Even at the > theoretical level this is a bad idea. It is a leaky abstraction over a > simple request/response cycle. It made something simple and made it > overly complicated. This remind me of Hibernate and ORMS. I disagree > that we should abstract things to this level and do everything in verbose > Java. > People are dropping Hibernate and going back to native SQL and Spring > JDBC template. SQL and the relational model are easy. Working with > HTTP requests is easy too. What was wrong with JSPs/Servlets? Keep > it simple stupid. We know JSF was too complicated and it was > terrible. Spring MVC is better and has rest support. It just works > with Spring and has great support for the JSON Jackson mapper. > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-F > ramework-tp4080411p4080411.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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
