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 ;]

Paweł Kamiński


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

Reply via email to