Rick Reumann wrote:
Nick's comment on here about a week ago got me to at least look at Wicket. http://wicket.sourceforge.net/ Has anyone actually used it for a real-world application? I'd be curious on your thoughts.
I looked at Wicket quite a bit too, having heard a lot of good things about it...
So far, with my limited two days of looking over the examples and example code, I'm not so sure of it's place in the framework world. My biggest contention is with the claim on the page http://wicket.sourceforge.net/Introduction.html "Wicket is all about simplicity. There are no configuration files to learn in Wicket. Wicket is a simple class library with a consistent approach to component structure. In Wicket, your web applications will more closely resemble a Swing application than a JSP application. If you know Java (and especially if you know Swing), you already know a lot about Wicket."
I completely agree... I've seen some butt-ugly Swing code in my time, and probably have written some of it if I'm being honest, and one thing I would *not* call it is simpler than a reasonably-designed and implemented config-based framework.
There are some interesting ideas in Wicket, no question, but it's not any simpler in my estimation, it's just moving complexity elsewhere (which is the complaint I often hear, and myself have, about JSF by the way).
"Wicket, more than any other framework gives you a separation of concerns. Web designers can work on the HTML with very little knowledge of the application code (they cannot remove the component name tags and they cannot arbitrarily change the nesting of components, but anything else goes). Likewise, coders can work on the Java components that attach to the HTML without concerning themselves with what a given page looks like. By not stepping on each other's toes, everyone can get more work done."
*THIS* was my biggest problem... I don't see how it can remotely even be described as "separation of concerns"... to me, even the best Swing code is a jumbled mess of presentation and application code. Oh sure, you can do some things to make it less so, but your still describing presentation in terms of code. That means my Java developers have to be my page designers, and vice-versa. How exactly are my concerns separated again?
Since I'm the one always having to handle the html in my JSPs anyway, the above isn't that big of a deal to me.
And you just hit the nail on the head... if your in a shop where the Java coders and the page designers are one in the same, as frankly many of us are, then much of this doesn't matter (both pro and con). You can pick a framework for whatever reasons you want and have at it and probably be successful.
It's when you get into a shop where there are two separate groups doing these things that the decision becomes a lot harder... well, to me, it gets *easier* to decide against Wicket and similar frameworks. In fact, as much as it pains me to say it (because I don't particularly care for it), something like JSF begins to have more benefit in such an environment.
-- Rick
Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
