I wrote an article called The top 8 reasons I don’t use Wicket. Turns out it’s a pretty controversial topic (who’d have thought?). In one of the comments, Igor Vaynberg, who contributes a lot to the Wicket framework, responded to my article point by point. I started to write a reply and I realized that it was getting so long that it made sense to just make a new article out of it. My previous article wasn’t about Wicket vs Stripes, but I’m going to make this article about that.
Before I start, I just want to say that when I was using Wicket, Igor was without a doubt the most helpful person on the IRC channel and mailing list. He holds an incredible amount of knowledge about the Wicket framework and is always willing to share it.
1) there are three books available. the mailing lists are indexed by sites like nabble and markmail which make it trivial to search them. google indexes the lists also. the wiki is a wiki – it is user-contributed thus the quality varies – i think everyone understands this and takes it for granted.
I already mentioned this and addressed it in detail. But, more importantly, the difference between Wicket and Stripes is that with Stripes, you’ll be doing a lot less searching in the first place. It’s just easier to use! In fact, if you read the quick start guide, a mere 3 pages or so, you’ll basically “get” Stripes and pretty much be ready to make a complete webapp right off the bat. When you do have questions, most answers are literally right on the homepage. Seriously, how much easier can it get?
2) if you have no OO skills, which from reading this post i can clearly see you do not, wicket indeed has a high learning curve because it makes heavy use of OO principles.
you want to override a tag attribute: override the function that generates it Component#onCompoentTag(Tag tag) and use the provided tag object to modify attributes. Or use a provided convenience AttributeModifier to make this easier and shared behavior across component instances.
you want to append something to the head element: override the method that generates it IHeaderContributor#renderHeader(IHeaderResponse response) and use the provided response object to write something into the head. or use the provided convenience HeaderContributors to make this easier and shared behavior across component instances.
you want to make a component’s visibility dynamic? override the method that controls it: Component#isVisible() and return true or false based on your needs.
you want to output dynamic value between some tag’s you attached a component to? override the method that generates that value: Component#onComponentTagBody(..) and use the provided arguments to write out the body. Or use the convenience Label component that makes this easier.
see the pattern now?
Um, poor communication skills? 
Sorry, I’m just kidding. Seriously, IMHO, this isn’t easy or convenient. You know how you do every one of these things in Stripes? A conditional JSTL tag. The same thing you’d do in Struts. The same thing you’d do in any web framework that uses JSPs.
This has three huge advantages:
- If you already know JSTL, learning Stripes will be even quicker.
- If you don’t know JSTL and you learn Stripes, you learned something that is directly transferable to many other web frameworks. On the other hand, when you learn Wicket, you learned something that is only applicable to Wicket, AFAICT.
- There are lots of taglibs out there that are web framework agnostic. You can use these in Stripes even if they weren’t originally intended for it. This knowledge is also directly transferable.
Back to Igor:
3) java code is more structured and thus is easier to maintain, refactor, improve, evolve, and change. the compiler for java is a hell of a lot better at catching errors early then a compiler for
markup..oh, wait, there isnt one.
Yes, I agree. And that’s why I pull as much logic as I possibly can into my Java classes. Sure, display logic has to exist in JSPs: Wicket has that on Stripes. But I consider it worth it. Read the 8 points of my previous post to see why. Stripes doesn’t have any of these problems.
> Wicket doesn’t have an official list of, “Cool features that will save you tons of time” anywhere, so you’ll likely have the same experience as me.
Wicket’s cool feature is that all the dynamic behavior is in java code. but obviously you didnt get that.
Well Stripes’ cool features are that it’s easy to learn, use and it stays out of your way. Regarding that last point, Stripes is very “thin” but is doing very helpful things behind the scenes (I suggest readers look at this Struts1 vs Stripes article to learn more). Most of the time you barely notice it’s there.
4) apparently tons of people who have created components that integrate from yui to gmaps do not share your opinion. you can see them all in wicketstuff.org.
i bet i can create a component that elegantly integrates this javascript captcha into wicket and makes it transparent. just because you couldnt doesnt mean it is impossible. the awesome thing about wicket is that once i do it i can jar it up and anyone else using wicket can reuse it in their project with little or no effort. let me know if you want to put your money where your mouth is
Not really sure where you’re coming from here. I already made a Wicket ReCaptcha library and posted the source on the mailing list. I also already made a Stripes ReCaptcha library and posted the source on the wiki.
But anyway, I’m sure you could have made the Wicket one better than I did. You have the advantage of actually writing part of the framework. But, for those of us that haven’t written the web framework they work in, let me tell you that the Stripes version was much easier to create.
5) why would you use wicket to generate javascript or css? wicket generates xml markup, thats it. if you do want to do this we do provide a texttemplate helper that can be used to generate dynamic text tidbits. there is also velocity panel if you prefer to use velocity for this.
OK, while I go off and google how these two components work I’ll explain how you’d do this in Stripes: A conditional JSTL tag. See the pattern now?
6) once again, this goes back to you not having the OO skillset. there is nothing wrong with anonymous classes. the cool thing is that if you find yourself in a situation of writing the same kind of anonymous class over and over you can simply refactor an anonymous class into a top-level class and reuse it. the ide will do all the work for you.
I disagree. Anonymous inner classes are ugly and hard to read. They also make the class that creates them difficult to unit test.
If we’re going to consider the convenience that using an IDE brings the picture, I should point out that there’s a Intellij IDEA plugin that will reduce the potential errors you’d get in JSPs when using Stripes.
7) i am using wicket on a project now where a designer goes into our source tree and modifies the look and feel of the website. he had to work on jsps before and now swears by wicket. this happened on a project i worked previous to this one in a different company. and the same before that. maybe you are a one-man team so you dont see the benefit.
My current company isn’t huge but it’s got > 50 software engineers. But regardless, I already acknowledged on the previous post that Wicket is one of the best frameworks in this category.
Now, that being said… who cares? Seriously, I’ve never worked at any company where the average amount of developer time spent on the appearance of the site even came close to 20%. When I edit JSPs, I spend most of my time adding new forms, inputs, and other miscellaneous dynamic parts to my already existing pages. And that, in my opinion, is where Stripes puts its emphasis on productivity.
I’ll let the readers be the judge by comparing two apps that do the same thing: You enter a field in a form, submit it, and it echos the same message back to you.
Here’s the Wicket version (got the source one of the example pages):
HTML
<?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <title>Wicket Examples - echo</title> <link rel="stylesheet" type="text/css" href="style.css"/> </head> <body> <span wicket:id="mainNavigation"/> <form wicket:id="form"> <input type="text" wicket:id="msgInput" value="" size="50" /> <input type="submit" value="set message" /> </form> <span wicket:id="msg" id="msg">Message goes here</span> </body> </html>
Java
package org.apache.wicket.examples.echo; import org.apache.wicket.examples.WicketExamplePage; import org.apache.wicket.markup.html.basic.Label; import org.apache.wicket.markup.html.form.Form; import org.apache.wicket.markup.html.form.TextField; import org.apache.wicket.model.PropertyModel; /** * The simplest form application possible. Just prints any user input to a label. * * @author Eelco Hillenius */ public class Echo extends WicketExamplePage { private String message = "[type your message to the world here]"; /** * Constructor. */ public Echo() { // This model references the page's message property and is // shared by the label and form component PropertyModel messageModel = new PropertyModel(this, "message"); // The label displays the currently set message add(new Label("msg", messageModel)); // Add a form to change the message. We don't need to do anything // else with this form as the shared model is automatically updated // on form submits Form form = new Form("form"); form.add(new TextField("msgInput", messageModel)); add(form); } /** * @return the message */ public String getMessage() { return message; } /** * @param message * the message to set */ public void setMessage(String message) { this.message = message; } }
JSP
<%@ page contentType="text/html;charset=UTF-8" language="java" %> <%@ taglib prefix="stripes" uri="http://stripes.sourceforge.net/stripes.tld" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head><title>Echo</title></head> <body> <stripes:form beanclass="com.example.EchoActionBean"> <table> <tr> <td><stripes:text name="message"/></td> <!-- ${actionBean} is the actionBean that took you to this JSP. Always an EchoActionBean in this example --> <td>${actionBean.message}</td> <td><stripes:submit name="printMessage" value="Submit"/></td> </tr> </table> </stripes:form> </body> </html>
Java
package com.example; import net.sourceforge.stripes.action.ActionBean; import net.sourceforge.stripes.action.ActionBeanContext; import net.sourceforge.stripes.action.DefaultHandler; import net.sourceforge.stripes.action.ForwardResolution; import net.sourceforge.stripes.action.Resolution; import net.sourceforge.stripes.action.UrlBinding; @UrlBinding("/home") public class EchoActionBean implements ActionBean { private ActionBeanContext actionBeanContext; private String message = "[type your message to the world here]"; public void setContext(ActionBeanContext actionBeanContext) { this.actionBeanContext = actionBeanContext; } public ActionBeanContext getContext() { return actionBeanContext; } public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } @DefaultHandler //Every time you visit "/home", this method gets called and forwards you to the JSP public Resolution printMessage() { return new ForwardResolution("/WEB-INF/jsp/home.jsp"); } }
agreed. stateless/bookmarkable stuff IS harder then stateful code in wicket. if you have an app that is totally stateless you should probably not use wicket. however, most apps i worked on, have only a small portion of functionality exposed as public pages, the bulk of the functionality – usually the one with a complex ui – is behind a login page where google cant index it and bookmarkability is not important. you have to choose the right tool for the job.
Just because a webapp is partially or even mostly stateful doesn’t mean you should use Wicket to develop it. Tim Fennell, the creator of Stripes, actually has a comment about this from an awesome article (I highly recommend it, the creators of 11 web frameworks discuss the pros and cons of what they’ve created) written in 2006:
[I]magine a Google homepage where you could pop open multiple search panels and search and page through results etc. in each panel. Each time you hit next on one panel, the whole page would be refreshed, the panel you clicked on updated, and all the other panels left as they were.
Managing a UI like this in a way that is multi-window safe can be very difficult. This is the problem that component-oriented solutions like Wicket and JSF were designed to solve. My view is that for 90%+ of web applications, component-oriented frameworks are overkill, and that for another 9%, AJAX is more a more effective way to manage a stateful UI as described above.
{ 2 trackbacks }
{ 27 comments… read them below or add one }
If you’re writing a relatively simple application (the Echo example is very simple), you don’t need the added complexity of a framework like Wicket. Stripes (which is definitively a great choice from the range of model 2 frameworks) will do fine, and it’s simplicity is a good thing. However, the more complex the applications you write, the more you’ll enjoy the benefits of being able to abstract out commons behavior, work with custom reusable components and have all the code that matters statically typed etc. I would be the last one in the world to propose Wicket as the tool for all needs, but I wouldn’t recommend any framework or technology as such. Though I wouldn’t say that for 90% of the web applications component oriented frameworks are overkill, maybe more along the lines of 60% or so. But that’s arbitrary.
This article seems more to the point than the last one.
Stripes appears to almost share characteristics with the Jersey RESTfull stuff in the way URL’s map. I’m going to have to look into that, thanks for the link to Tim Fennell’s article.
Echo example? Seriously? Is this how you want to compare two web frameworks?
This is just silly. Let’s forget about simple applications for now – this is where stripes probably has advantage. Most webapps I’ve been working on are intranet applications with complicated stateful user interface mimicking desktop applications (in fact many of them were “ports” of desktop applications). Those are apps with complicated pages (i.e. tabbed panel inside tabbed panel, three separate forms, two dozens of links/buttons, paging table and a tree, you get the idea). With stuff like this model 2 frameworks are conceptually too limited to elegantly handle such complicated state, doesn’t matter if it’s struts or stripes. Sure it’s nice that you can quickly hack in a field in form, but what if you need to add a pageable table to a page that already has two of them and a tree?
It’s scenarios like these when you appreciate what real component frameworks provide – the way to encapsulate behavior as “real” components (that you can bundle as jar and ship, easily extend and combine).
I don’t even want to start with Ajax. Want to have partial page update in Wicket? Change Link to AjaxLink. Button to AjaxButton. Chose the components you want to update. It can’t really get much simpler. And it scales. No matter how complicated your component hierarchy gets, Wicket takes care of generating proper markup ids, of updating the selected parts of page, of submitting and processing forms. In most common cases you don’t even have to know how javascript works.
With big projects you don’t really care about couple of extra lines of java code. What you care about is project that doesn’t silently break when you refactor the model. With wicket you can have models that are completely refactor-safe. Something you can only dream about with code like this:
Btw. I’ve yet to seen a real world project where jsps haven’t turned into huge unmaintainable mess as the project grew. Really.
And your objection to anonymous classes. I really don’t know what to say. Anonymous classes are commonly being used in Swing or SWT (which are UI frameworks conceptually close to wicket) and somehow no one finds it’s strange. We have to live with the syntax until java gets proper closures (like that’s ever going to happen…).
The code that didn’t make it in the previous comment:
[td][stripes:text name="people[${loop.index}].username” value=”${person.username}”/][/td]
Replace [ ] with < and >
As has been pointed out, using the “echo” example to compare frameworks is really lame. I happen to have a much better example here:
http://ptrthomas.wordpress.com/2007/04/01/jtrac-ui-makeover/
This article linked above contains links to the JSP source (which btw is a great example of what happens when you have too much of the JSTL conditional tags that you love so much
and for comparison – the corresponding Wicket HTML and Java source.
Heh, I really don’t think many would agree with that sentiment and the post linked above also proves how easy it is for designers to tweak the HTML and plug in CSS and images. More details about how Wicket makes life easy for designers can be found here:
http://www.mysticcoders.com/blog/2009/03/09/5-days-of-wicket-day-1/
Of course, maybe your designers are experts in JSTL conditional tags
I’ve said it before on your other blog and I’ll say it again. A designer can’t maintain your stripes application. If they load your view into Dreamweaver it will look like someone threw up on their screen.
The importance of the designer to be able to “change things” easily and independantly (look Ma, no developer!) is astronomical on any large web application. I, like you, though tag libs were the answer about 3 years ago, then I saw Wicket and instantly knew otherwise.
But at least you can say you’ve given them both a shot and find Stripes to be the one for you, that’s more than most can say. I have similar feelings about certain a ORM at times, but I’ll keep my comments to myself lest I be added to the lynching
Man oh man,
I bought the Wicket in Action book and read it from page to page up until the Composition chapter (I believe chapter 7) and I just gave up. I mean, I don’t care tall the reading and learning curve of Wicket. The idea of this framework is pure and revolutionary but it is just too convoluted. I often found myself searching endless hours on the web to find wicket documentation (not the official one). I guess Wicket or any other framework like it (Tapestry) for example is a great thing! This is no doubt about it. But it would be a long shot before component framework like those could really replace JSP technology. JSP technology is just so fundamental! Framework like Struts/Stripe/Spring MVC plays nicely with JSP technology and make web development an evolutionary. Not like Tapestry/Wicket, they are the *revolutionary* ones. And people often feel repel to revolution. Unless it’s really change their life.
Cheer
I prefer Stripes to Wicket too.
I’m really surprised that you name JSTL and JSPs as a feature. Or Struts. Those have been the worst things about Java web development. Seriously.
As a few people already said, if it’s for a few pages with a few forms and such, Wicket (or Tapestry, for that matter) has indeed a pretty steep and potentially useless learning curve, you’re better off with PHP. Or Grails, RoR, Stripes.
Couldn’t agree more with Matej and Eelco: when it really gets tough, complex and when the application has a long maintenance, having most in Java code (even if verbose) is a clear winner. Plus the ability to encapsulate UI code into components of their own. Not that Wicket is perfect, but it does an excellent job at that.
The world is ever moving.
Model 1 : plain JSP
Model 2 (MVC, action based, page navigation) : Struts, Stripes etc
Model 2.5 (component based, page navigation with some AJAX) : Wicket, JSF
Model 3 (comp. based, single page interface, AJAX intensive and Comet) : GWT, ItsNat, IceFaces
I invite you to try ItsNat
http://www.itsnat.org
Though, ItsNat is in the same space of Wicket, dynamic behavior is code in Java, and static layout is HTML, this in my opinion is a strong benefit because OOP is a blessing to mange big and complex applications and productivity is highly improved in this type of applications.
Of course in “Hello World” applications or typical Model 2, frameworks based on Model 2.5 and Model 3 are overkill… It seems you like action frameworks, non-OOP with logic mixed with HTML static layout… definitively Wicket or ItsNat is not for you.
Java framework diversity is nice because of the freedom, the multiple ways/styles/approaches of coding, use the tool you feel comfortable.
@It all comes down to : Abstraction! Abstraction! Abstraction!
I’m not a heavy wicket user, I use all kind of tools, so long as it gets the job done in “best” way (not fastest/least_coding, but a balance of all factors).
In dismissing Wicket, the article shows such shortsightedness in development its painful to see.
Nobody can argue what OO concept is bringing to programming complexity management. As requirements grow with multiple teams, no scripting language can achieve an acceptable level of complexity-manageability comparing to OO. Take the scripts out (I mean ALL the scripts), that leaves Action-based and component based OO frameworks.
90% overkill? Sounds like what Bill Gate said about 640kB memory back then. We’re going faster and faster, meaning more complex systems going online. Even Adobe Flash that’s been enjoying 9x% share can’t do without a OO flex framework (component-based). Everything..and I do mean everything in the application (not a bunch of pages with images and include-scripts, that was 1988) is encapsulated, the behavior, the look-feel, the data, the callback. They are all wrapped up in their respect class waiting to be reuse, spawn as object, or to be unit-tested individually (if u want). Every tags, every forms, every actions/behaviors, can be manipulated using 20 millions java libraries out there dynamically.
And of course this is high-learning curve, like when you first learn Java after 20 yrs in Cobal.
Wicket, or any other component-OO frontend web kits are here to stay, it might not be the tool for simple things, but a medium to large project, they are very efficient, tactical weapons in a programmer’s toolbox.
jmarranz: You wouldn’t miss one article to pimp itsnat. Also even with component applications sometimes you need certain amount of bookmarkability and possibility for crawlers to index your application. Good luck with that with Ajax only frameworks.
Matej, ItsNat and Wicket share some common approaches, in some way a similar development style. When Wicket promotes pure HTML templates and Java for the view-logic, is promoting ItsNat too, and when ItsNat promotes this approach is promoting Wicket.
The real “competing” development styles are GWT (client centric and view programmatically built) and JSF based or similar (declarative programming mixing view logic, business logic and layout in the same file).
In ItsNat related threads usually some people ask for comparing it with Wicket and I have no problem to deal with it, polite technical discussions are ever fine.
By the way, bookmarking is possible with single page interface applications.
http://www.innowhere.com:8080/itsnat/feashow_servlet?itsnat_doc_name=feashow.main&feature=feashow.core.bookmarking.ex
Mostly it is all where you are coming from
If you are raised in the age of Struts yes, you cant really program (sorry to say that, but in my experience this is really just the reality)
Before i used Struts (from version 0.5+ on) i already did a lot of Swing programming.
So if you come from Swing or you really know how to do OO programming you dont have to search that a lot how to do stuff in Wicket. Why because it is natural. At least that was what happened in my case. (and maybe i just read code instead of tutorials)
Let me put the reliance upon inner-classes in context. Have you used an event-driven tool for rapid development of GUI applications — such as Visual Basic? You put components on the form; you click on an event, and then you write an event handler. The event is merely something that happens during the component’s life, and the event handler is an optional description of work to be done when that happens.
Java was not designed for a RAD (rapid application development) environment; it has no built-in concept of such things as properties, property editors, events and event-handlers for assembling components in a graphical builder environment. So what is the Java analog to “creating an event handler for an event raised by a component”?
Here is one way you can do it. The component writer defines a do-nothing method that the component calls whenever the event occurs. If you want your component to handle the event, you instantiates not the raw component itself, but rather a subclass of the component that handles the event by _overriding_ the component’s do-nothing event handler.
Now, you could create this subclass in a separate file under a carefully thought-up name, but why bother? All you are doing is adding an event handler! You’re not going to add this specific event handler to any other of these components. Furthermore, the event handler probably needs access to other objects in the environment of the page or panel that instantiates the component. So you create the subclass of the component in the context of the enclosing page or panel’s constructor — hence, an inner class. And since this is the only instance of this component with this event handler that you plany to create, why bother giving a name to this class of objects? Therefore you make the component an instance of _anonymous_ inner classs.
Now, you may ask, “Why should I have to do this? Why can’t I just do like in JSF (as distinct from JSP) or ASP.NET? Click on the component icon on a tool page, and then click on my form to add the component; open the component’s property editor and click on the event; the tool generates a method header that I fill in with the event-handling code. I can even do this in Swing with a good IDE.” The answer is that creating components that work in these builder tools is a huge PITA. You’re just not going to do it. You’ll leave that to Microsoft. You’ll just paint every individual detail of every screen, every form — using the components you’re given — and you’ll leave component development to the professionals.
There’s a reason sophisticated Swing developers ignore the builder tools of their IDE and code the interfaces by hand. If you have to worry about installing your components into some IDE’s graphical builder (along with any needed property editors), then it becomes _really_ easy to modify, extend, or specialize components in code. It is very easy to create classes that assemble groups of components into a panel, for instally into pages a whole panel at once. You can document that panel where it’s defined, and then use it in many places, (anonymously) subclassing it as needed in each instantiation.
The RAD approach may suffice when you’re doing simple things. If your IDE is a standard (Visual Studio), provided by monopoly power (Microsoft) that commands the services of an army of third-party professional component sellers, you can even do some complicated things — provided you find, buy and install the components you need. We in the Java world don’t have that luxury. The price of making components easy to build and extend is that component creation techniques become fundamental to component usage.
That said, if properties and closures were added to the Java language, then Wicket could look more like conventional fat-client RAD languages. We’d be able to add an event handler to an event-handler collection just like in C#, without needing to sublcass components just to use them. It might even make sense to provide a GUI builder in the IDE for people who needs are conventional and who do not suffer from too much repetition in their designs. I think a version of Wicket tailored to C# would be awesome!
I think one thing is forgotten in this discussion and I hope I don’t sound condescending when I say this, I think wicket is a perfect fit for Java developers while most other frameworks fit for web developers in general.
If you write complex business apps, you would realize wicket is a great choice and probably the best. If you look at large bussiness software vendors in last decade (oracle, peoplesoft etc), they have all used some sort of gui component based technology to drive their software suites. However, It is not a solution to every problem. For content oriented site, it is better to go with scripting solutions.
In that example you used for comparison, what was your point? Number of lines?
If that was the case, if you strip the comments (things like, ‘/** Constructor */’ and ‘/** returns the message */’), blank likes, and use the same code conventions (inline curly brackets), the code becomes 9 lines (and 581 bytes) shorter than Stripes’!
Wicket:
=========================================
Wicket Examples – echo
Message goes here
package org.apache.wicket.examples.echo;
import org.apache.wicket.examples.WicketExamplePage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.PropertyModel;
public class Echo extends WicketExamplePage {
private String message = “[type your message to the world here]“;
public Echo() {
PropertyModel messageModel = new PropertyModel(this, “message”);
add(new Label(“msg”, messageModel));
Form form = new Form(“form”);
form.add(new TextField(“msgInput”, messageModel));
add(form);
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
=========================================
Stripes:
=========================================
Echo
${actionBean.message}
package com.example;
import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.Resolution;
import net.sourceforge.stripes.action.UrlBinding;
@UrlBinding(“/home”)
public class EchoActionBean implements ActionBean {
private ActionBeanContext actionBeanContext;
private String message = “[type your message to the world here]“;
public void setContext(ActionBeanContext actionBeanContext) {
this.actionBeanContext = actionBeanContext;
}
public ActionBeanContext getContext() {
return actionBeanContext;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
@DefaultHandler //Every time you visit “/home”, this method gets called and forwards you to the JSP
public Resolution printMessage() {
return new ForwardResolution(“/WEB-INF/jsp/home.jsp”);
}
}
=========================================
(trying again, escaping point brackets to keep the markup)
In that example you used for comparison, what was your point? Number of lines?
If that was the case, if you strip the comments (things like, ‘/** Constructor */’ and ‘/** returns the message */’), blank likes, and use the same code conventions (inline curly brackets), the code becomes 9 lines (and 581 bytes) shorter than Stripes’!
Wicket:
=========================================
<?xml version=”1.0″ encoding=”UTF-8″?>
<html xmlns=”http://www.w3.org/1999/xhtml” >
<head>
<title>Wicket Examples – echo</title>
<link rel=”stylesheet” type=”text/css” href=”style.css”/>
</head>
<body>
<span wicket:id=”mainNavigation”/>
<form wicket:id=”form”>
<input type=”text” wicket:id=”msgInput” value=”" size=”50″ />
<input type=”submit” value=”set message” />
</form>
<span wicket:id=”msg” id=”msg”>Message goes here</span>
</body>
</html>
package org.apache.wicket.examples.echo;
import org.apache.wicket.examples.WicketExamplePage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.model.PropertyModel;
public class Echo extends WicketExamplePage {
private String message = “[type your message to the world here]“;
public Echo() {
PropertyModel messageModel = new PropertyModel(this, “message”);
add(new Label(“msg”, messageModel));
Form form = new Form(“form”);
form.add(new TextField(“msgInput”, messageModel));
add(form);
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
=========================================
Stripes:
=========================================
<%@ page contentType=”text/html;charset=UTF-8″ language=”java” %>
<%@ taglib prefix=”stripes” uri=”http://stripes.sourceforge.net/stripes.tld” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html>
<head><title>Echo</title></head>
<body>
<stripes:form beanclass=”com.example.EchoActionBean”>
<table>
<tr>
<td><stripes:text name=”message”/></td>
<!– ${actionBean} is the actionBean that took you to this JSP. Always an EchoActionBean in this example –>
<td>${actionBean.message}</td>
<td><stripes:submit name=”printMessage” value=”Submit”/></td>
</tr>
</table>
</stripes:form>
</body>
</html>
package com.example;
import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.Resolution;
import net.sourceforge.stripes.action.UrlBinding;
@UrlBinding(“/home”)
public class EchoActionBean implements ActionBean {
private ActionBeanContext actionBeanContext;
private String message = “[type your message to the world here]“;
public void setContext(ActionBeanContext actionBeanContext) {
this.actionBeanContext = actionBeanContext;
}
public ActionBeanContext getContext() {
return actionBeanContext;
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
@DefaultHandler //Every time you visit “/home”, this method gets called and forwards you to the JSP
public Resolution printMessage() {
return new ForwardResolution(“/WEB-INF/jsp/home.jsp”);
}
}
=========================================
Oh, sorry, I’ve forgot to strip some comments from the Stripes example. Wickets’ is ‘only’ 8 lines and 370 bytes shorter.
Comparing Stripes vs Wicket is like comparing apples vs bananas.
One is an action-based framework while the second is component-based.
You like Stripes because of #1 you don’t wan’t to move from action-based flow to component-based hierarchy, or #2 you can’t do #1.
Cheers,
Bruno
Great article, I wonder have you ever tried spring.
Seriously, read this four-year-old (excellent) post: http://technically.us/code/x/java-vs-ruby-on-rails-deathmatch/
Especially the last sentence.
Can Wicket fan tell me if we have to choose component base model over model 2, isn’t zk (http://www.zkoss.org/) is a much better framework than Wicket. It has all the features of Wicket plus out of the box excellent Ajax support. I used both Wicket and ZK, and honestly after using ZK, I am not sure why some one wants to go back to Wicket.
Great article. I’ve been using wicket for a month or two on a project and agree with the author’s points. A lot of simple things are very difficult to do in wicket and extremely unintuitive. You can pick through the mailing list and they’ll say, just do this weird thing or that weird thing – how would we even know to do that? I think you need to understand the internal workings of wicket in order to use it. It’s definitely not well documented.
The thing about this article is that it seems to be misnamed.
The title should be \Try to answer Igor’s point instead of Stripes vs Wicket\.
There is no clear explanation of why a particular approach is better in Stripes, just statements that point out they are different.
And the side by side code comparison. What does that achieve?
My own experience with Wicket seems to be entirely different. Mailing list was helpful. The hints that Igor and other drops are extremely helpful. Yes, they seldom spell out solution for script kiddies (I wonder how many millions of those there are) who typically rely on cut and paste examples to achieve anything, but if you recall your OO (which sadly had been allowed to degrade with scripting) understanding what they mean usually just requires you to think about the component and in worst case scenario, navigate to the JAVA code of that component.
People who complain about Wicket not being maintainable probably have NEVER maintained any medium to large scale systems. Maintainability is NOT about how quickly you can change your code. It’s more about how easily your colleague can come back months/years later and understand your code for him/her execute a Change request. With a pure JAVA implementation. All I need is another Java programmer, ok maybe ones untainted by model-2; they did take the Swing course in their Sun certification, I don’t even need Wicket programmers. With markup heavy frameworks, I don’t have that luxury. 3 years down the road, what’s Stripes you say? Oh, forget it and just rewrite everything with my brand new framework, we have lots of cut-and-paste ready examples for your monkeys, oops, programmers…. With Wicket, the only situation that’ll occur is when everyone forgets Java.
Wicket is really a great framework; Sure, it can be rough at start; All that it takes is some time to get back to old OO school principles and start thinking again with abstraction, composition and patterns.
Oh man, I’ve been spending years scripting code in JSP and now I’m finally getting back to real programming! Wicket is wonderful when it comes to creating reusable and extensible components; At my actual job I’m just creating a component stack on top of Wicket and I’ve no words in telling how easy is for the other team members to use the components I’m writing and coding complex applications with minimal effort! They have just to create their Page class extending “SecuredContentPage” and voila’! they get a complete Web Page, full with css stylesheets (overloadable and with branding capabilities, of course), a menubar (horizontal/vertical), footer, content area with title, maximizer button etc etc.. All Corporate Web application pages shares a common theme, behavior and presentation; And If I write a beautiful pageable data table I can turn it into a reusable component and save days of coding to my happy fellows. I’ve no words in telling how happy I’m with using this beautiful framework!