The Framework That Helped Me Enjoy Web UI Programming
Friday, October 30th, 2009
I hate web UI programming. I despise web UI programming. You have all that tag soup. Tag libraries and HTML and javascript and CSS hacks and business logic, oh my! No matter how much you fight to keep it all separated, it seems to run together.
You have to use clunky flows and add all this extra code to pass session variables around, held together with string constants. And if not that, then you have to deal with bloated frameworks that were designed by tool vendors (*cough* *JSF* *cough*) and don’t solve the tag soup problem. (Granted, the guys at JBoss have taken a lot of the hurt out of with JSF with Seam.)
MVC, we have tried and tried, and I personally never seem to be happy that I have actually done a good job modeling my implementation after you. The Model 2 style of Actions and Flows is awkward at best and confusing most of the time. Why can’t we write webapps like we write desktop apps, using a component-based model and none of this tag soup mumbo jumbo?
In comes Apache Wicket. Wicket is component based, but it is a lot more like Swing than JSF. You don’t have to use a stateless programming model. You can keep references to objects without putting them in the session. For real. It would be hard not to do it that way with Wicket.
Wicket separates the presentation markup from the business logic. For real. It is actually separated. I have been working on a large project using wicket for the past 8 months and we have done this again and again. The framework even enforces it. Your designer could make changes to your copy of the mockup that you put in source control and not have to worry about breaking your code. GWT (which is also component-based and liked by me) doesn’t do that. But having the designer be able to make the changes to some weird CSS bug in IE 6 is a dream come true for java developers who build highly functional websites that are ugly.
You can also do all the UI updating you can do with Swing and Wicket does the same things with AJAX. Plus, you don’t have to write any javascript! For real. It just works. Even in IE 6.
So, for those of you who hate Model 2 MVC (Struts, Struts 2, Spring MCV and Spring Webflow, and even dare I say it, Grails, etc.) and want something where the idea of creating a reusable component isn’t an exercise in frustration and you want to get rid of the tag soup (sorry JSF), then give Wicket a try.
Sounds like someone is ripe for JavaFX…
Try doing a matrix of radio buttons on a form in Wicket.
We are right now moving all our applications from JSP to Wicket.
Can’t wait until we’re done
“Try doing a matrix of radio buttons on a form in Wicket.”…
This can be done in multiple ways. If you didn’t manage to find a simple way, it doesn’t mean it doesn’t exist. In wicket you can do anything a simple way and also a wrong way. Trust me, I’ve seen a code written in wicket which was horrible. But this doesn’t mean that the framework is the problem, rather the developer who doesn’t care about the clean code too much..
Hi. I use Wicket from version 1.3 in my free time. I like it, before I used JSF but I found this one more useful for my work. I also tried JavaFX but I din’t like it. I think it depends from project. At this moment I use Wicket and for me it is the framework that helped me enjoy web UI programming.
Thanks for the post.
Try Vaadin – it’s similar to Wicket and GWT, but for me it seems to be easier and more convenient. You don’t event have to create HTML like in Wicket. Only Swing-style code.
http://vaadin.com
I am not opposed to trying out JavaFX, I just need time to actually do it.
Swing is dead, Swing pattern is bad thing, Web is best, why learn from Swing ,Swing should learn from Web.
Web framework should be REST, RESTful framework is truly Web Framework.
you have stand on a wrong way.
Banq, I would disagree very strongly with you that Swing should be learning from the web. The very presence of frameworks like Wicket and client side technologies like AJAX, or even Javascript itself is about building into the web what it lacked as far as building desktop type applications. The web has been the student of the desktop since the first cgi-scripts written in perl started making the web serve up dynamic content instead of the static documents it was originally designed for.
In my experience, the stateless Model 2 MVC that most web application frameworks have used leads to very clunky, difficult to reuse and difficult to maintain code. Programmers who only know this style of UI programming are missing out on the power of Object Oriented Programming in their UIs, and I think they could all learn a lot from working on a well-built desktop app with a strong event-driven component model.
You also argue that REST is the true web, and I would agree with you 100%. I think RESTful web services are much easier to understand, much easier to model and offer much better reuse than RCP-style SOAP based web services. However, I think part of the reason REST works so well is that you are getting back to what the web was designed for, and that is document exchange, not interactive applications. SOAP is so heavy weight because it is building interactive semantics on a platform that was originally designed for document exchange. Even though I would never choose SOAP when REST is an option, I don’t know that REST would have grown to become popular if we hadn’t first felt the pain of trying to bring RPC to the web.
“Swing” and “The Web” are not at odds with each other.
Andrei Solntsev: “Try Vaadin … You don’t event have to create HTML like in Wicket. Only Swing-style code.”
I glanced at their website; it sounds like an interesting approach. It sounds like Echo2 approach, but using GWT as its rendering engine (instead of however Echo2 is implemented).
Most Wicket developers also like Echo2, so they’ll probably also like programming in Vaadin.
My guess is that Wicket probably gives you more flexibility in that you have the full power of HTML/CSS at your disposal, should you want it, but given that power it does the best job of keeping all program logic (display logic, too — not just business logic) out of the tag files.
However, if you can do without the ability to use any HTML/CSS feature you please and are willing to be limited by the look-and-feel options provided directly by the framework, then a framework such as Vaadin or Echo2 that does away with ugly tag files (e.g. HTML) completely is probably the way to go.
@Alex,
Please share how you can do a matrix of radio buttons with wickets, as the developers I was working with couldn’t get it to work.
We’re talking 3-4 columns with a dozen rows of selections. The user can select one radio from each column. Because of how the tags are written out in wickets and the radios grouped, this was not possible. We had to switch to checkboxes, and then add a lame error message if someone clicked more than one checkbox per column.
@Eric G,
I have written a wicket page that had four columns of about ten radio buttons – for a total of about 40 options. The user is allowed to select one option from each group.
I used a combination of div tags to separate the columns with wicket AjaxCheckBox components in each of the columns. Let me know if you need more and I’ll try and get you a code snippet.
I have used Echo2 previously as well, and I liked the programming model, but not the rendering engine and the way that it handled styles. A GWT-style rendering engine would be an improvement for Echo2.
Jeff,
right, last I saw on EZ they were checkboxes. You got the array of radios to work later?
Matt, could you expand on where you said:
> You can also do all the UI updating you can do with Swing and Wicket does
> the same things with AJAX. Plus, you don’t have to write any javascript!
You’re not saying that Wicket gives you Swing-like UI experience, just that you can update text field values w/o having to refresh the page, right? Does Wicket’s use of Ajax mean that I have to learn Ajax, or is the Ajax hidden, and all I need for a Wicket-based webapp is Java+HTML+CSS?
Wicket is very Swing-like in it’s control over the UI. You can do full replacement of entire sections of the page just by swapping or updating a component much the same way you would in Swing. It is much more than just text updating and replacement. You can trigger the updates from a wide variety of events as well. As for the AJAX implementation, it is completely hidden. You can inject your own javascript code if you really want to, but it is not needed. I not at all an HTML+CSS+Javascript guy (they are part of what I hate about Web UI programming), so for me, having that funcationality from Wicket and being able to write all of it in java is awesome. Plus, with the way Wicket handles templates, if you have a designer, they can handle all the HTML+CSS on their own and can still edit the templates that you check in with your code.
[...] you look at my previous blog posts, you know that I despise view technologies that force you to write tag soup. In the aforementioned [...]