well, I have nothing against writing my own SQL with spring;] but it is true that before I read wicket in action I was like a child in fog :/
after JSP I started palying with tapestry and tapestry has a bit better introduction pages. it is not that there is not enough information around but wicket lacks free introduction that shows the wicket way (but maybe I could not find it). looking at wicket stuff is hard at the beginning. I tried vaadin and tapestry and I still find wicket as very nice framework anyway I would never ever go back to JSP ;] pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski....@gmail.com ______________________ On 18 November 2011 10:35, Chris Colman <chr...@stepaheadsoftware.com> wrote: >>Breaks POJOS: A real POJO does not need to implement an interface or >>extend a class. > > A object oriented framework is a foundation on which you extend your > application. Back in the C++ world there was MFC, OWL, .Net, etc., In > the Java world there was AWT and then Swing etc.,. All event driven, > object oriented component based frameworks. All were pretty easy to > build desktop applications in. > > Most of an application's UI elements extended from core classes in the > framework. That's just how you use OO frameworks. If you want to write > UI elements that do not extend or implement classes of interfaces of a > 'framework' then you're not really using any framework and reinventing > the wheel. > >>Bad Defaults: Most pages are stateless. > > Every page in our app is stateful. We show the username of the current > user at the top of the page after logging on and we also have a panel on > the right that shows alerts specific to the current user. Sure the main > content of each page is not delivered differently per user but many of > the auxiliary components are. > >>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. > > We use a component resolver. That can make it possible for the HTML > markup to drive the component hierarchy without explicitly adding > components in Java code each time you want to add a new component. > >>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. > > My examples of desktop app frameworks above were all event driven, > object oriented, component based frameworks. This model evolved to be > *universal* in the desktop world for a good reason - it's a damn fine > architecture IMHO and obviously in the opinion of the rest of the world > of desktop application developers. > > Einstein said, "Make something as simple as possible but not too > simple". Request/response is just too simple to be useful for anyone who > has come through from the desktop application world and 'gets' event > driven, object oriented component based architectures. > > When I moved from desktop to web development I went CGI, servlets, JSPs, > Struts, Echo and now Wicket. Until I started using Echo & Wicket my web > app days were never as fun or 'clean' as ye olde desktop app days. For > me Wicket is the ONLY web UI framework that gives me the same kind of > development productivity and clean, reusable application source code > that I enjoyed in the desktop app development world. > > >>It made something simple and made it overly complicated. This remind > me of Hibernate and ORMS. > > Yeah, ok, if you're not using an ORM in your apps by now and still > spending your days writing SQL glue code then we need to have a talk ;) > > Chris > > --------------------------------------------------------------------- > 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
