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]

Reply via email to