On 1/20/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Rick Reumann wrote: > > "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.
All above is exactly my feel about Wicket. I was very enthusiastic about it half a year ago, but frankly speaking, I do not like Swing-type convoluted coding. Maybe I just don't know a proper technique to write Swing code, but it always ends up with a bunch of global variables used throughout several classes and event handlers. > That means my Java developers have to be > my page designers, and vice-versa. How exactly are my concerns > separated again? You can preview HTML template it in a browser. I guess you can do the same with JSF and Netbeans, do you? And with JSP as well, even without web.xml file. So, the preview thing does not seem like a showstopper for me. > > 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. In many (most?) cases page "designers" know shit about programming, they just draw fancy images in Photoshop and slice-and-dice them into a table. If a web "designer" knows what CSS is and how to create fluid and scalable page, he is already a pro ;-) I mean, I personally cannot draw, but I can connect dots, I mean, lines here and there. I understand that XHTML/CSS/Javascript is a huge area to learn, but do web "designers" know all this stuff? Well, maybe there should be a GUI developer position, who can take slices and build nice web page and not be shy to run it in Tomcat. Wicket and Tapestry are not *the* solution for the gap between web "designers" and server-side developers. > 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. +1 We are building apps, not pieces of art. Take panel, drop. Take button, drop. Take combobox, drop. Change properties. Wire up events. Voila. Design? Can be applied later with CSS. ASP.NET 1.0 produced shitty non-XHTML markup, hopefully this version is better. Hopefully JSF is better too. If all that JSF rendereres produce are divs and spans with proper ids, then dressing up a page would be a weekend fun a-la Zen Garden. Anyone from JSF team hears me? ;-)))) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
