Apache Wicket is a Flawed Framework

[Andrea Del Bene-2]

On 17/11/11 16:44, Eric Kizaki wrote:
> 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.
>
Wicket is NOT based on MVC, so there's nothing to violate :). From
Wicket in Action: "Wicket components represent the View and Controller
in this pattern (MVC)"
> Excessively verbose and complicated:  What is a LoadableDetachableModel?
> The learning curve for Wicket is immense.
>
> 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.
if you had understood LoadableDetachableModel (or at least used it) you
would not say "breaks POJO".
> 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
??! do you know that Wicket is a Java framework and not a JavaScript
(client side) library?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[chrisco484]

>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: [hidden email]
For additional commands, e-mail: [hidden email]

[kamiseq]

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

[hidden email]
[hidden email]
______________________



On 18 November 2011 10:35, Chris Colman <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jens Jahnke]

Hi,

On Fri, 18 Nov 2011 11:04:39 +0100
kamiseq <[hidden email]> wrote:

K> but it is true that before I read wicket in action I was like a
K> child in fog :/

I totally agree with that.

I'm just starting with wicket and without the book I think I would have
dumped it because there is not much free documentation. Although I find
most other web frameworks suffer in that region too. ;-)

Regards

--
18. Nebelung 2011, 11:36
Homepage : http://www.jan0sch.de

Right now I'm having amnesia and deja vu at the same time.
                -- Steven Wright

[Hielke Hoeve-2]

If you come here and try to start a flame about how bad Wicket is while you obviously have no clue how it works then atleast have the decency to write a propert post instead of a lame list of cons (and no pros) and a oneliner saying Spring MVC is the only other option...

Hielke

-----Original Message-----
From: Eric Kizaki [mailto:[hidden email]]
Sent: donderdag 17 november 2011 16:45
To: [hidden email]
Subject: Apache Wicket is a Flawed Framework

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.
 
Not previewable:  One of the supposed benefits of Wicket is a clean template that could make pages previewable for designers.  First, we don't have seperate designers at my company.  Second, it is better if the samer person does development and design.  Third, if you use extends your page will not be priviewable outside an application server running Wicket.  This supposed benefit does not exist.

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.

Excessively verbose and complicated:  What is a LoadableDetachableModel?
The learning curve for Wicket is immense.  

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-Framework-tp4080411p4080411.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Gaetan Zoritchak-2]

I started with the book wicket in action so it was ok. Before choosing a
technology I look at the number of existing books and I buy the best one.
But I'm not sure that every body does like me.

My main problem is the wiki. The pages are often very old explaining things
that do not apply with the last version of wicket.... and the wiki si so
slow that I can't imagine working on it to update the pages :(

2011/11/18 robert.mcguinness <[hidden email]>

> i'm baffled when people say the documentation is poor, the javadocs are
> excellent and like igor said there are some great books (blogs too!).
>  books
> and blogs get outdated fast since technlogy is rapidly advancing, so *use
> the source luke!*.  Not only will you learn Wicket, but I guarantee your
> Java skills will improve.
>
>
> awesome examples:
>
>
>
> https://github.com/apache/wicket https://github.com/apache/wicket  (scan
> over the unit test, best way to learn any framework not just wicket)
>
> https://github.com/55minutes/fiftyfive-wicket
> https://github.com/55minutes/fiftyfive-wicket  (fantastic)
>
> https://github.com/42Lines https://github.com/42Lines
>
> https://github.com/wicketstuff/core https://github.com/wicketstuff/core (a
> gem, tons of examples on how to pretty much do anything)
>
> http://code.google.com/p/wiquery/source/checkout
> http://code.google.com/p/wiquery/source/checkout
>
> https://github.com/jolira/wicket-stateless
> https://github.com/jolira/wicket-stateless  (wicket stateless is
> excellent,
> even easier with wicket 1.5)
>
> https://github.com/reaktor/oegyscroll
> https://github.com/reaktor/oegyscroll
> (endless pagination)
>
> http://code.google.com/p/wiquery/source/browse/core
> http://code.google.com/p/wiquery/source/browse/core  (jquery)
>
> http://code.google.com/p/jqwicket/source/browse/
> http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from the
> code and roll your own if it doesn't fit your needs, super easy
>
> https://github.com/rjnichols/visural-wicket
> https://github.com/rjnichols/visural-wicket  (great ui tools)
>
> https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/
> (excellent!)
>
>
>
> rob
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Martijn Dashorst]

On Thu, Nov 17, 2011 at 4:44 PM, Eric Kizaki <[hidden email]> wrote:

Thanks for taking the time to vent your frustrations. I don't see any
reason to start to ridicule you, or to think you are an incapable
developer just because you don't like Wicket and have taken the time
to get it off your chest.

Wicket is not suitable for everyone, not suitable for every
application, not suitable for every situation. We don't claim such,
and neither do we force anyone to use Wicket. If you don't like what
you see, too bad, move on to something you do like.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Josh Kamau]

Gaetan;

I also like starting from a book. Then read the (scattered) docs and wiki
when am looking for a solution to specific issues. Some projects have an
official user guide that is downloadable as pdf or read online as html. I
know documentation is one of the the most boring tasks for developers but
its is necessary. May be we should hire someone to do the user guide. The
users can donate to pay him.

My 2c.

Josh.

On Fri, Nov 18, 2011 at 2:45 PM, Gaetan Zoritchak <
[hidden email]> wrote:

> I started with the book wicket in action so it was ok. Before choosing a
> technology I look at the number of existing books and I buy the best one.
> But I'm not sure that every body does like me.
>
> My main problem is the wiki. The pages are often very old explaining things
> that do not apply with the last version of wicket.... and the wiki si so
> slow that I can't imagine working on it to update the pages :(
>
> 2011/11/18 robert.mcguinness <[hidden email]>
>
> > i'm baffled when people say the documentation is poor, the javadocs are
> > excellent and like igor said there are some great books (blogs too!).
> >  books
> > and blogs get outdated fast since technlogy is rapidly advancing, so *use
> > the source luke!*.  Not only will you learn Wicket, but I guarantee your
> > Java skills will improve.
> >
> >
> > awesome examples:
> >
> >
> >
> > https://github.com/apache/wicket https://github.com/apache/wicket  (scan
> > over the unit test, best way to learn any framework not just wicket)
> >
> > https://github.com/55minutes/fiftyfive-wicket
> > https://github.com/55minutes/fiftyfive-wicket  (fantastic)
> >
> > https://github.com/42Lines https://github.com/42Lines
> >
> > https://github.com/wicketstuff/core https://github.com/wicketstuff/core(a
> > gem, tons of examples on how to pretty much do anything)
> >
> > http://code.google.com/p/wiquery/source/checkout
> > http://code.google.com/p/wiquery/source/checkout
> >
> > https://github.com/jolira/wicket-stateless
> > https://github.com/jolira/wicket-stateless  (wicket stateless is
> > excellent,
> > even easier with wicket 1.5)
> >
> > https://github.com/reaktor/oegyscroll
> > https://github.com/reaktor/oegyscroll
> > (endless pagination)
> >
> > http://code.google.com/p/wiquery/source/browse/core
> > http://code.google.com/p/wiquery/source/browse/core  (jquery)
> >
> > http://code.google.com/p/jqwicket/source/browse/
> > http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from
> the
> > code and roll your own if it doesn't fit your needs, super easy
> >
> > https://github.com/rjnichols/visural-wicket
> > https://github.com/rjnichols/visural-wicket  (great ui tools)
> >
> > https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/
> > (excellent!)
> >
> >
> >
> > rob
> >
> > --
> > View this message in context:
> >
> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
> > Sent from the Users forum mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

[heikki]

I have tried out the Wicket framework and many things I really like about it. Some observations:


- Wicket changes drastically between versions, and even between minor versions / release candidates, things suddenly disappear from the API, sometimes without having been flagged as deprecated ;

- as a result, many times the example code you find on the web or in books like 'Wicket in Action' does no longer work as is

- the Javadoc of the source is quite OK for some classes, but for the great majority any textual explanations there are either sparse or absent

- luckily the mailing list is nothing short of fantastic !

- I agree that it is rather too easy for Wicket to make things stateful, when you don't want it

- and in my opinion the stuff you need to do to achieve "normal" URLs (no ?, no version number, no nothing) is just a pain. *Every* URL, for stateless or stateless pages or whatever, should be "normal", otherwise it is just not acceptable -- users never want to see those complicated-looking URLs under any circumstance

- did not yet try out Ajax with Wicket, so I have no opinion on that

Just my 2¢. In all, a great framework that is much easier to use than e.g. things based on JSP. Keep up the good work, guys !

Kind regards
Heikki Doeleman

[Josh Kamau]

"- did not yet try out Ajax with Wicket, so I have no opinion on that "

In my opinion, ajax is the killer feature. Give it a try.

Josh.

On Fri, Nov 18, 2011 at 3:07 PM, heikki <[hidden email]> wrote:

> I have tried out the Wicket framework and many things I really like about
> it.
> Some observations:
>
>
> - Wicket changes drastically between versions, and even between minor
> versions / release candidates, things suddenly disappear from the API,
> sometimes without having been flagged as deprecated ;
>
> - as a result, many times the example code you find on the web or in books
> like 'Wicket in Action' does no longer work as is
>
> - the Javadoc of the source is quite OK for some classes, but for the great
> majority any textual explanations there are either sparse or absent
>
> - luckily the mailing list is nothing short of fantastic !
>
> - I agree that it is rather too easy for Wicket to make things stateful,
> when you don't want it
>
> - and in my opinion the stuff you need to do to achieve "normal" URLs (no
> ?,
> no version number, no nothing) is just a pain. *Every* URL, for stateless
> or
> stateless pages or whatever, should be "normal", otherwise it is just not
> acceptable -- users never want to see those complicated-looking URLs under
> any circumstance
>
> - did not yet try out Ajax with Wicket, so I have no opinion on that
>
> Just my 2¢. In all, a great framework that is much easier to use than e.g.
> things based on JSP. Keep up the good work, guys !
>
> Kind regards
> Heikki Doeleman
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082988.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[Chantal Ackermann]

Hi all!

Thanks for this list, Rob!

Not that there would be any more to say except:

* I've never seen so informative and extremely helpfull Exception/Error
messages in any framework or tool so far.
Thank you!
* Concerning the "ugly" URLs: well, I don't think that the "real" users
out there bother so much. (But you should still aim to the most perfect
solution, for the honour...)
Working with APEX I've realized that there are blogs based on APEX - and
hey, compared to APEX' URLs, wicket's are a treat...

Cheers,
Chantal

On Fri, 2011-11-18 at 04:35 +0100, robert.mcguinness wrote:

> i'm baffled when people say the documentation is poor, the javadocs are
> excellent and like igor said there are some great books (blogs too!).  books
> and blogs get outdated fast since technlogy is rapidly advancing, so *use
> the source luke!*.  Not only will you learn Wicket, but I guarantee your
> Java skills will improve.  
>
>
> awesome examples:
>
>
>
> https://github.com/apache/wicket https://github.com/apache/wicket  (scan
> over the unit test, best way to learn any framework not just wicket)
>
> https://github.com/55minutes/fiftyfive-wicket
> https://github.com/55minutes/fiftyfive-wicket  (fantastic)
>
> https://github.com/42Lines https://github.com/42Lines 
>
> https://github.com/wicketstuff/core https://github.com/wicketstuff/core  (a
> gem, tons of examples on how to pretty much do anything)
>
> http://code.google.com/p/wiquery/source/checkout
> http://code.google.com/p/wiquery/source/checkout 
>
> https://github.com/jolira/wicket-stateless
> https://github.com/jolira/wicket-stateless  (wicket stateless is excellent,
> even easier with wicket 1.5)
>
> https://github.com/reaktor/oegyscroll https://github.com/reaktor/oegyscroll 
> (endless pagination)
>
> http://code.google.com/p/wiquery/source/browse/core
> http://code.google.com/p/wiquery/source/browse/core  (jquery)
>
> http://code.google.com/p/jqwicket/source/browse/
> http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from the
> code and roll your own if it doesn't fit your needs, super easy
>
> https://github.com/rjnichols/visural-wicket
> https://github.com/rjnichols/visural-wicket  (great ui tools)
>
> https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/ 
> (excellent!)
>
>
>
> rob
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Daniel Neugebauer]

I was searching for a Java framework two years ago because I wanted
server-side persistence and a statically typed language with the option
for easy AJAX and debugging while the output markup is largely
maintained the way I wrote the templates.

I think I found Wicket via DZone due to the 1.4 release. I already read
a book from Manning before and liked that it was written in a way that
enables the reader to jump right into programming after having read the
introductory chapters. I was happy when I saw that Wicket in Action
seemed to use a similar structure. I think I tried Wicket without the
book first but got stuck really quick (at latest when I got to the point
when I needed models which was quite immediate) and so buying WiA was a
quick (and good) decision.

As with any framework, it takes at least one project to get your head
around it, so you better start with some personal project in your free
time. On the following 2-3 projects you are iterating on the "maybe I
could have done it better that way" process. But that's just the way it
is for any framework in any language (and also without any framework at
all). I assume the OP is using Wicket the first time without any
guidance and just hasn't found into it yet.

I wasn't able to put Wicket in use at work until January this year but
now we are on our 2nd (my 4th) Wicket project. What I could observe is that

1) you usually don't find into Wicket until you read a book
    (with WiA it's sufficient to read the introductory chapters, jump
    into coding and come back to the chapters whenever you need to know
    something)

2) there is an aversion until you get your head around the correct use
    of models and anonymous inner classes, at least if you never did
    something like that before
    (WiA introduces it quite good but you have to start coding before
    you really get it)

3) you should follow the (excellent) mailing list to read about issues
    you may encounter and use it as a knowledge base once you hit some
    problem/question
    (better on an own email account than on the archives)

4) if documentation does not help, read the source code
    (I found it pretty readable which is much different from other
    frameworks I have used/tried before - being easily accessible with
    Maven and a decent IDE, there is no excuse not to look into it)

So, the conclusion is: There should be better free documentation but if
you pick up a book it's quite easy to get started and the best 30€ ever
spent.

> - I agree that it is rather too easy for Wicket to make things stateful,
> when you don't want it

To turn that into a point of critique: It may be hard to get stateless
pages.

I've made a similar experience where I had a search form that would not
go stateless. I couldn't figure out where anything was persisted but if
I had dug deeper, I may have found the cause, but that issue wasn't
important enough to invest more time in it.

> - and in my opinion the stuff you need to do to achieve "normal" URLs (no ?,
> no version number, no nothing) is just a pain. *Every* URL, for stateless or
> stateless pages or whatever, should be "normal", otherwise it is just not
> acceptable -- users never want to see those complicated-looking URLs under
> any circumstance

I prefer the way Wicket handles persistence with at-most-once semantics
by simply adding version numbers on the URL (after a redirect from an
internal URL) as other methods are less successful in achieving that out
of the box, pollute URLs even further or add hidden markup. IMO, two
numbers on the URL are quite unobtrusive, especially as they are simply
ignored and transparently reassigned if the session does not match (i.e.
on a URL that has been pasted into an email etc.).

> - did not yet try out Ajax with Wicket, so I have no opinion on that

It's incredibly easy to use; you should really try it. :)

> Just my 2¢. In all, a great framework that is much easier to use than e.g.
> things based on JSP. Keep up the good work, guys !

Full ack! :)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Eric Kizaki]

I was not expecting so much hate.  I guess now I am infamous in the Java world now.  Look, it is just my opinion.  Not many people actually stopped to address many of my points.  They just immediately bashed me.

I am sticking with Wicket because it is required for work.  I am able to do stuff in it but it seems unnecessarily complicated.  I own the “Wicket in Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok Tong.  The second book is much more practical.  Without these books I would not be able to do anything in Wicket.  That is why I did not mention documentation.  I would prefer to just be able to check out something like this http://static.springsource.org/docs/petclinic.html.  This is a real working application that shows how to do things with databases etc.  With Wicket, I had to string a bunch of snippets together and read two books.  I am still not sure I am doing things the best way.

To people who say I am inexperienced, I have tried JSF and GWT.  Wicket is better than both of those.  JSF has an invasive and complicated lifecycle.  When I saw the lifecycle diagram I just stopped even looking into it.  GWT uses terrible Swing style layouts and all these crappy interfaces for RPC.  There was also no real help on the server.  At least with Wicket I can still use HTML and CSS for my layouts.  However, these component based frameworks are still way too complicated for a simple task:  building a web page.  In my humble opinion Spring MVC done right (no scriplets) with JSTL & EL and jQuery is better than Wicket.  You can also use Velocity templating.  I have also used Swing to build desktop apps.  I would not say Swing is a shining example of how to build GUIs.  I thought it was pretty bad, verbose, and impractical.  The Play Framework has the right idea:  stateless and restful.  No clunky components and over-engineered objected-oriented baggage.  

Here is a quote from the Restlet page (http://www.restlet.org/about/introduction):
“While powerful for complex centralized models, the object-oriented paradigm isn't always the best suited for Web development. Java developers need realize this and start thinking more RESTfully when developing new Web servers or new AJAX-based Web clients. The Restlet project is providing a simple yet solid foundation that can get you started right away on the Web 2.0.”
- Jérôme Louvel, Restlet founder
Maybe you can look up his Linkdin and start bashing him too.  Oh no he said object-oriented is not the Holy Grail!

I am definitely in the “I like to hand-code HTML, CSS, and Javascript” camp.  I even like hand-coding SQL.  I get complete control.  These are all pretty easy languages; most of them are declarative.  They are easier than Java.  I know most Java developers do not feel this way and want to just do everything in Java.  I think you should use the best tool for the job.  Java is a mediocre tool to use in every domain.

[Adam Gray]

That's actually interesting you feel that way because I was just making the
comment that I was surprised at how little hate was being displayed.  Sure
there are a couple here and there, but par for the internet is far, far
lower (higher? maybe a golf analogy was a bad idea) than what we're seeing
here.  And, in fact, many people did attempt to address specific issues.
 However, you can't really expect sunshine and rainbows when the initial
post says nothing positive whatsoever and offers no suggestions for
improvement.  This more recent post, however, I like so much better because
you actually get into specific instances where there is room for
improvement and link to a potential guide for a solution.

I would definitely agree with you that something like the spring petclinic
would be really handy.  I, personally, can't count the number of times I
found myself "doing it wrong" because I hadn't known to look at the javadoc
in that other class over there (I'm looking at you, ListView vs DataTable).
 One of the largest strengths of wicket is its flexibility, but it tends to
come at the cost of there being too many ways to do something.  That makes
it difficult to know which is the "right" way to accomplish the task.
 Until you really get to know wicket, it definitely feels a bit like you
need to learn the secret handshakes and hidden incantations to make it do
something as simple as showing feedback properly in a repeating view.
 There are a lot of us here that have gone through (and still going) that
learning curve and could probably contribute to a large sample application
that shows "how to do stuff".

Additionally, I believe work on Wicket 6 has officially started, so if
there are concrete suggestions for improvement, I bet Jira would love to
record them for you.  Is Wicket perfect?  No, no framework is.  But it's
getting better and the more help it has, the better it will get.

On Fri, Nov 18, 2011 at 9:27 AM, Eric Kizaki <[hidden email]> wrote:

> I was not expecting so much hate.  I guess now I am infamous in the Java
> world now.  Look, it is just my opinion.  Not many people actually stopped
> to address many of my points.  They just immediately bashed me.
>
> I am sticking with Wicket because it is required for work.  I am able to do
> stuff in it but it seems unnecessarily complicated.  I own the “Wicket in
> Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok
> Tong.  The second book is much more practical.  Without these books I would
> not be able to do anything in Wicket.  That is why I did not mention
> documentation.  I would prefer to just be able to check out something like
> this http://static.springsource.org/docs/petclinic.html.  This is a real
> working application that shows how to do things with databases etc.  With
> Wicket, I had to string a bunch of snippets together and read two books.  I
> am still not sure I am doing things the best way.
>
> To people who say I am inexperienced, I have tried JSF and GWT.  Wicket is
> better than both of those.  JSF has an invasive and complicated lifecycle.
> When I saw the lifecycle diagram I just stopped even looking into it.  GWT
> uses terrible Swing style layouts and all these crappy interfaces for RPC.
> There was also no real help on the server.  At least with Wicket I can
> still
> use HTML and CSS for my layouts.  However, these component based frameworks
> are still way too complicated for a simple task:  building a web page.  In
> my humble opinion Spring MVC done right (no scriplets) with JSTL & EL and
> jQuery is better than Wicket.  You can also use Velocity templating.  I
> have
> also used Swing to build desktop apps.  I would not say Swing is a shining
> example of how to build GUIs.  I thought it was pretty bad, verbose, and
> impractical.  The Play Framework has the right idea:  stateless and
> restful.
> No clunky components and over-engineered objected-oriented baggage.
>
> Here is a quote from the Restlet page
> (http://www.restlet.org/about/introduction):
> “While powerful for complex centralized models, the object-oriented
> paradigm
> isn't always the best suited for Web development. Java developers need
> realize this and start thinking more RESTfully when developing new Web
> servers or new AJAX-based Web clients. The Restlet project is providing a
> simple yet solid foundation that can get you started right away on the Web
> 2.0.”
> - Jérôme Louvel, Restlet founder
> Maybe you can look up his Linkdin and start bashing him too.  Oh no he said
> object-oriented is not the Holy Grail!
>
> I am definitely in the “I like to hand-code HTML, CSS, and Javascript”
> camp.
> I even like hand-coding SQL.  I get complete control.  These are all pretty
> easy languages; most of them are declarative.  They are easier than Java.
>  I
> know most Java developers do not feel this way and want to just do
> everything in Java.  I think you should use the best tool for the job.
>  Java
> is a mediocre tool to use in every domain.
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4083476.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

[hfriederichs]

heikki wrote

- and in my opinion the stuff you need to do to achieve "normal" URLs (no ?, no version number, no nothing) is just a pain. *Every* URL, for stateless or stateless pages or whatever, should be "normal", otherwise it is just not acceptable -- users never want to see those complicated-looking URLs under any circumstance

Here I totally agree. I think there are very few developers who understand this. An URL is a technical entity, and, if they had a choice, the vast majority of internet-users could very well do without it.
URL's are not user friendly.

It's better now, but in the early days it was very cumbersome to help my >80 father (y'all understand >80, I presume) on the phone: 'No, dad, just type h-t-t-p-:-/-/.....'.

I really think this is a flaw in wicket, caused by a collective blank spot of it's otherwise very clever developers.

But I really love Wicket, I managed to develop a quite complex application that's robust and easy to use, and it's only my second web application ever, the first being a Servlet with html-spawning only...

[Gaetan Zoritchak-2]

> The Play Framework has the right idea:  stateless and restful.
> No clunky components and over-engineered objected-oriented baggage.
>
>
Play has some advantages but also shortcomings and presents significant
risks. The transition from version 1 to version 2 will require re-writing
the code. No migration possible! The new version seems to focus
on scala (the views are now coded in scala instead of groovy). The business
code can be in java and scala. What will happen to the java version in 2
years? Play's vision is a fully integrated technology stack with
fairly fixed choices (JPA data access for java, Anorm - single
layer over jdbc - for scala).

This is not the approach of wicket which is much more modular and
simply treat the presentation layer.

In short, there is no silver bullet ... just find the framework that best
meets your needs.

[Igor Vaynberg-2]

i will address some points that i dont think have been addressed yet...

On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki <[hidden email]> 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-Framework-tp4080411p4080411.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Brown, Berlin [GCG-PFS]]

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:[hidden email]]
Sent: Friday, November 18, 2011 1:50 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Alex Objelean]

First of all, sorry for my previous comment. It was wrong judging you instead discussing the points addressed in your post. Nevertheless, nobody hates you for your opinion :). This kind of posts appears from time to time and there is nothing wrong with them as long as these address valid issues (which is not the case this time). You cannot please everybody.

The only problem is the way you titled your post - that is the real bashing. When writing this kind of post, don't forget that you are bashing not only the framework, but also the time and effort of the people who contributed to this open source project. A constructive critique is always appreciated.





 

[Jonathan Locke]

Needless to say, I don't particularly agree with most of the criticisms listed.

And for the right job, Java isn't half as bad as you seem to think. I'd say the trouble is Java vs. the JDK (and other libraries). While Java itself is still reasonably cool, there is a lot of real crap out there. And there's plenty in the JDK! But if you're determined to program well, you can wrap and hide the majority of this crap quite excellently in Java. What you're left with is a screaming fast server-side programming language with more support in terms of platforms and functionality than anything in history. While I'd love to see a Scala where I can read 90% of the source code out there at a glance like I can with Java, I'll stick with Java (at least on the server side) for now.

Given that you hate Wicket and Java (and have a LOT of energy for that given the length of your post), why don't you switch jobs? You sound unhappy with your gig. And although the economy is down, software is actually quite hot and there are a lot of jobs for people that just want to hack on loosely typed UI scripts. Heck, I'm getting emails from headhunters almost daily. I'd say life is too short to lump it. If Wicket doesn't suit you, switch frameworks. If it's required at work and that makes you hate your job, switch jobs.