A Wicket user tries JSF
May 14, 2007 112 Comments
A year or so back I attempted to learn JSF and even bought one of the recommended books. But after reading through the first hundred or so pages, I came to the conclusion that it was too complicated and un-intuitive. The code samples looked ugly to me in a way that was difficult to explain. The fact that there was a different expression language (with a ‘#’ instead of ‘$’) to get used to when I was just getting comfortable with JSP EL did not help either.
So I gave up trying to learn JSF and decided to concentrate on Spring MVC at that time.
Fast forward to today and the main trigger for my current experiments with JSF is because after my recent blog post on migrating from Spring MVC / WebFlow to Wicket, I am increasingly being asked whether I ever tried JSF.
So I have attempted to write a very simple application (based on MyFaces) and I will try to compare it side by side with the exact same functionality implemented in Wicket. I just started with JSF a couple of days back so feel free to comment and let me know if I missed something fundamental and I will update things either in this post or the next.
Functionality
This is supposed to be a “discussion forum” application and there is only one domain object called “Forum” with two String fields “name” and “description”. Maybe in the future I will include “Topic” and “Message” objects but for now I’m trying to keep things as simple as possible.
There are only two screens. The home page is a list of Forum(s) in the system. There is a link to create a new Forum. This brings up the other screen which is a form with two text fields and a submit button. After a successful submission, you are taken back to the home page and the newly created Forum appears in the list.
Environment
NetBeans 5.5 is being used. I deploy to a Jetty instance that I set up manually because I want to also compare the Jetty “footprint” required for Wicket vs MyFaces. With some digging I’ve tried to arrive at the bare minimum “quickstart” config required, for example the web.xml file cannot be possibly smaller. I’m using Maven2 directory and naming conventions. Defaults are used as far as possible. In the side by side comparison images below JSF is on the left and Wicket is on the right.
So here goes:
Project Structure
- Wicket does not require any extra XML config like you have faces-config.xml for JSF
- Wicket does not require JSPs
- By default, Wicket expects the markup (*.html files) to be side by side with the *.java files corresponding to components – e.g. Page(s). Some people find this a bit odd but this keeps things simple and there are some very good reasons for this. You can change this convention if you really want to.
- The MyFaces application requires an “index.jsp” welcome-file to redirect to the virtual home page URL
Jetty Footprint
Since Wicket does not require JSP support – the Jetty footprint is much smaller – the contents of the Jetty “lib” folder come down from 6.16 MB to 692 KB
Library Dependencies
Even without using Tomahawk etc., MyFaces requires far more dependencies than Wicket i.e. 10 vs 4 JAR files
faces-config.xml
Wicket does not require any kind of XML configuration at all and the “faces-config.xml” file does not have any equivalent. Navigation logic is performed in pure Java code which is much more flexible and type-safe and you don’t need to synchronize multiple files.
web.xml
A servlet filter handles all the framework stuff in Wicket. This has some advantages like you can map the root of your context path “/” to the home page. Anything not meant for the Wicket filter like images, css reources etc. will be ignored by the filter.
You need to tell Wicket where your “Application” class is located. This Application class is used primarily to point to the designated home page.
The Wicket Application Class
In a real life application, this is where you would manage references to the service-layer, configure security and various other things. Here we are just configuring the home page.
The “List Forums” Screen
- The wicket markup is pure HTML but the MyFaces JSP is a mixture of JSP, HTML, JSF tags and JSF EL
- In the case of Wicket you can see that the complexity clearly moves out of the markup into the Java code. In the JSF version, the only thing the backing class is doing is setting up the model / list
- You don’t need a specialized IDE to edit the Wicket version – HTML editing and Java editing support is sufficient. In the case of JSF you have to rely on IDE support when the UI gets complex
- If you make a spelling mistake in the JSF EL expressions – you won’t know until run time – but the Java code that renders dynamic data in the Wicket version does not have that problem, you benefit from your IDE syntax coloring, refactoring suppport etc.
- The JSF version is using a “dataTable” control. For Wicket we are using a ListView repeater control and creating a table manually. Even then, this is very simple code and you have much more control over the markup. The JSF dataTable documentation is not for the faint of heart and runs into a few pages. That is a lot of complexity you don’t need most of the time. BTW Wicket does provide a range of grid controls in the Wicket extensions project
- Instead of navigation rules defined in faces-config.xml and the need to synchronize this with the action /event names you use in your JSP or backing class – in Wicket you can easily navigate from page to page by using the right “Link” components or setResponsePage()
- Instead of using “id” which has a lot of significance in terms of (X)HTML – Wicket uses a namespace so “wicket:id” is the attribute you use to link your Java code and markup. Relying on the “id” attribute can lead to all kinds of unpleasant name collisions in JSF.
The “Create New Forum” Form
In addition to the points in the previous section:
- In JSF you declare and configure components in the markup and you have to use the right tags (e.g. h:form, h:inputText, h:commandButton) and the right attributes (e.g. to mark an input field as “required”). JSF is supposed to be a component oriented framework but I wouldn’t call them Java components and definitely not Object Oriented.
- In Wicket you use normal HTML tags in the markup and in the Java code, you instantiate and attach the core components (e.g. TextField) or extend them as required (e.g. Form). All the behavior, and things like setting a field as “required” happen in pure Java code.
- In this case for Wicket the value of the “wicket:id” attribute on the input text fields also serves as OGNL notation for HTML form –> POJO binding – which reduces the amount of configuration.
- Rather than rely on a h:panelGrid to layout the form fields it is easier and more intuitive to use plain old HTML tables for this purpose.
- The screenshot below demonstrates how the “ForumFormPage.html” file looks like when opened in a browser. Being valid HTML, Wicket markup files can be previewed and edited as such. Wicket provides for true separation of concerns and HTML screen design and layout can *really* be done by a team separate from the Java development team
Generated HTML
The HTML generated by MyFaces is unbelievably verbose and contains all kind of strange javascript which I never, ever would have expected. If there is one reason to stay away from MyFaces, this is it.
You can click on the links below to see the output. If your browser renders the HTML instead of displaying the raw text, just do “view source”.
For Wicket, the generated HTML is clean like you would expect. And note that the Wicket specific attributes like “wicket:id” will be stripped in PRODUCTION mode.
Update [2007-06-10]: Simplified the wicket code for the “Create New Forum” form after it dawned on me that the existing POJO is more than sufficient for form binding. The older version can be found here: forum-form-screen2.png
The Java code for the Wicket form page can be made even more tighter using an anonymous inner class for the form. This is a nice example of how Wicket gets you to exercise the Java OO parts of your brain, and it is worth comparing this with the “ForumFormPage.java” above.
Update: I uploaded the Java and HTML source for the 2 Wicket pages. Since WordPress has restrictions on uploads (no *.zip allowed for e.g.), you have to rename the files correctly if you download them – Forum List Page: HTML / Java | Forum Form Page: HTML / Java
About Peter Thomas
Incremental Operations 
Can you fast forward to 2007? Look at JBoss Seam which makes JSF development much more pleasurable. Don’t get me wrong, I like Wicket and its philosophy but this isn’t a fair comparison to modern day JSF, especially with a trivial example as you’ve shown.
+1 on Hung Tangs comment.
JSF doesn’t require JSP, most people use facelets unless they are masochists.
Your Wicket beans have a ton of view code in them which blurs the separation of concerns.
The claim about the lack of compile time checking is somewhat misleading. A typo in the wicket page is just as vulnerable. When the new version of the JBoss IDE comes out it will (at some point) have page refactoring, and possibly design time checking of EL expressions.
There is less XML involved in using Seam, and much of it is annotation based. However, navigation rules are still xml based (but a different kind) which is probably the right thing.
Using JSF without Seam is like using a plain old servlet without Wicket.
Yes, I keep hearing that Facelets and Seam make JSF better. Anyway here I am starting out by trying to understand what the core JSF specification offers. I am not alone in concluding that the JSF spec needs improvement and that appears to be why frameworks like Facelets and Seam exist.
BTW there seems to be speculation as to whether Facelets is being actively maintained or not.
If you mean a typo in the markup and wicket:id attribute I agree – if you don’t use an IDE with Wicket support.
But since now most of the action happens in pure Java code (which is where it should be IMHO) I still stand by my statement. Look at “ForumListPage.java”
That reminds me, I did not cover error reporting – another area where MyFaces did not look good. In the Wicket HTML, if you mis-spell a wicket:id or get the nesting of components wrong, Wicket will tell you exactly where the problem is. And in development mode, you can edit the markup and refresh the web-page without restarting the web-app.
> “The claim about the lack of compile time checking is somewhat misleading. A typo in the wicket page is just as vulnerable. When the new version of the JBoss IDE comes out it will (at some point) have page refactoring, and possibly design time checking of EL expressions.”
This is not a real argument, is it? You are claiming about “possible features in the future”?
What about support to real-time changes in JSP pages? What about a real template technology? Right now you can choose between JSP (which is not recommended and works like crap) and facelets, which may or may not have an active community.
BTW, about the uglyness in this (simple) example, switching to facelets would not improve it a bit.
I am still expecting someone who has really tested other technologies and prefer JSF. This far, I have only seen people who don’t know better.
Thanks for this comparison, I really appreciate your work to put this up.
Regarding the comments so far:
– JSF and Wicket target the same audience in the same year (we have 2007 afterall, dont’ we?).
Why shouldn’t they be compared?
– This is a trivial example, but do you really believe that JSF shines on complicated ones ?
– In Wicket you program UI components, not ‘Wicket beans’. So I really don’t understand which separation is blurred.
– If using JSF without Seam is like using a plain old servlet, why did Sun bother to create the JSF spec ?
Spring Web Flow (SWF) also plugs nicely into JSF as an extension that combines the strengths of JSF’s component model which the strength of SWF’s navigation and state model.
See http://blog.interface21.com/main/2007/04/21/what-spring-web-flow-offers-jsf-developers/ for the essence of this support.
I too am surprised Peter didn’t at least mention the strength of JSF when you consider the ecosystem of quality extensions. As a standard with built-in extension points, it’s designed to facilitate vendor innovation and competition, and it’s done a pretty good job of doing that–with end users ultimately benefiting.
Keith
Keith,
I have used SWF and it is indeed an excellent solution for managing page-flows and page-navigation state.
After discovering Wicket I feel that especially when one needs fine-grained Ajax interactions with a web-page, one has to start thinking in terms of showing, hiding or refreshing individual components of a page – instead of one whole page at a time.
I discuss this in more detail towards the end of this blog post:
And, I’m personally not convinced that an ecosystem of extensions competing to make something that is supposed to be a standard usable – is a good thing.
Pingback: The “Break it Down” Blog » Blog Archive » Wicket vs JSF, Forum Application
Peter,
Excellent article. I’ve worked with both technologies, but seeing them side-by-side like this was very easy to follow and clear to read.
While some of the vendor-specific technologies mentioned above might make JSF easier, I think your comparison was fair.
I also agree with the previous posted that doing the same application using Facelets would have looked almost identical to the existing JSF app. I don’t understand why folks think Facelets is such an end-all-savior of JSF (the fact that it’s even needed to not make JSF a nightmare says something). It can be just as complex and a nightmare to deal with as complex JSP pages. To each his own I suppose.
FWIW, I’ve been using JSF since early 2004, and the comparison looks legit to me. Nice job, Peter.
I agree with you that a proliferation of competing component libraries which all deliver fairly basic functionality isn’t much of a “feature”.
Yeah. From my own viewpoint people that support their choice of frameworks in terms of industry standards and an “ecosystem of quality extensions” are pretty much saying “yeah, we know it’s crap, but it’s what everyone else is doing.” That’s fine for them, but I have no interest in that. I don’t want a framework, however standard, that’s going to fail me when things get really complex. Although I suppose this all goes without saying…
Very nice comparision. Regarding the ecosystem of components in JSF argument. IMO this is just marketing FUD. I am currently working at a major telco company and we have invested heavily in researching web-layer alternatives, including all those JSF projects. The bottom line was very dissapointing.
Its in fact not easy possible to mix JSF components wihtout being aware that you are mixing. JSF Projects like Icefaces are nearly a different world when you speak of interop between JSF components. If you plug in AJAX, every project will tackle that differently and if you are in luck, you even get prototype version collisions and stuff like that.
I mean, i like the marketing buzzword ‘ecosystem’, but in the world i live in, there is neither a healthy JSF component market, nor is it technically easy to mix component libraries.
JSF just doesnt deliver what it promised years ago.
I don’t quite see the point of mentioning Seam when comparing JSF.
Sure, it makes JSF somewhat more manageable, but still:
What is the quality of a framework (JSF) when you need to add additional frameworks just to make it workable?
Coming from Swing, I recently started to look at web technologies, and was really tempted by Wicket…and then NetBeans Visual Web Pack came along. The result is cosmetically really nice. I thought it was fine until I started to do things complicated like generating my tables myself (love the component, understand the need for a “model”, but gosh did I spent a lot of time on those DataProviders..!) Not to mention that I had to keep reminding myself of the stateless nature of the web…JSF’s “action listener” may look a lot like Swing’s but I got bit a few times when my Pagebeans got recreated with every click… All in all, I’m still not convinced I did well to go this route, maybe I should have stayed in the wing world..or am I missing something? Is Wicket really easier ? I have to say I’m not a fan of EL expressions…I feel like I have to learn a new langage!
all those
add(new Link(“home”) { public void onClick() { setResponsePage(HomePage.class); });
can be written as a one-liner
add(new PageLink(“home”, HomePage.class));
Yes. There’s even some very straightforwrd auto-linking support for creating simple navigations with (bookmarkable pages with no arguments only). Basically links inside can simply point to the relative HTML file and they will work in a design tool and be automatically linked up in Wicket.
Hah. I should have seen that coming. That last sentence should have said “…links inside <wicket:link> can simply…”, but word press ate my tag.
Well I never. PageLink indeed simplifies things a lot when there are no arguments. I just updated the code samples to address this point.
Jonathan I can imagine that would be useful in cases where you deliver a bunch of HTML prototype screens to end-users for sign off. That sounds like something interesting to try out.
I manage a project that started off innocently enough a year and half ago using SpringMVC and JSTL markup for the presentation tier. Acegi managed authentication/authorization. We soon added Displaytag for handling table layouts, Struts-Menu for a menubar, and SiteMesh for page decorating. Eventually we felt the need for more control over page navigation so we added SpringWebflow and found ourselves moving large amounts of decision logic and parameter passing into XML declarations. Later we needed more advanced components like calendars and trees, so we stitched JSF/Facelets/Tomahawk together with Webflow to handle those special cases. Most recently we needed better client response so we added in Ajax with DWR and a whole lot of javascript DOM code.
The surprising point is that among all of these frameworks there is very little overlap in functionality. Each fills a particular need and works really well. Considered individually, each framework seems well-designed and fairly straightforward to use (with the possible exception of JSF). But altogether they add up to an architecture that feels just barely manageable. Java programming is a distant land when tracking down a bug leads you on a lengthy excursion through JSTL loops and Spring bean bindings into thickets of XML declarations and decision-states and on down into a morass of Javascript DOM trees, only to find out that, “Oops, remember how we set up a specialized Sitemesh decorator to handle that page…”
If a framework exists that can do all this using only Java and HTML … well, today I’m downloading Wicket.
““The claim about the lack of compile time checking is somewhat misleading. A typo in the wicket page is just as vulnerable. When the new version of the JBoss IDE comes out it will (at some point) have page refactoring, and possibly design time checking of EL expressions.””
“This is not a real argument, is it? You are claiming about “possible features in the future”? ”
Actually this functionality has already been implemented, we are just waiting for it to be released. (There are several hurdles to the release, including legal ones.)
The example uses property models, which indeed are based on introspection (like EL). However, you can just implement IModel directly, and you’ll be as statically typed as you wish.
>If using JSF without Seam is like using a plain old servlet, why did Sun bother to create the JSF spec ?
For the same reason they created Servlet API. To use it as foundation for other frameworks like Wicket. You probably don’t use Servlet API directly, but it is needed anyway. The same is with JSF.
>What is the quality of a framework (JSF) when you need to add additional frameworks just to make it workable?
What is quality of Servlet API when you need Wicket to use it?! You are comparing apples and oranges – JSF was never meant to be full featured web framework, but specification that enables other vendors to build their components, frameworks, implementations etc on it.
>I am still expecting someone who has really tested other technologies and prefer JSF. This far, I have only seen people who don’t know better.
Over last 6-7 years I have used many web frameworks, from Struts, Webwork (now Struts2), Tapestry, plain JSF, different home grown frameworks, etc. Last few months I am using JSF with Jboss Seam and I can say that I am most productive with it. Maybe it is not solution for every application type (I haven’t chance to test it for high traffic applications) but definitively it works best for me.
I’d be curious to write this up in Tapestry just to see it side-by-side with Wicket sometime.
Pingback: Top Posts « WordPress.com
IMO, the Servlet / webapp specification is the most successful Java EE spec ever. For example a WAR file is 100% portable across all app servers. You don’t find so many people ranting about how Servlets suck, web.xml is complex – etc.
>IMO, the Servlet / webapp specification is the most successful Java EE spec ever. For example a WAR file is 100% portable across all app servers. You don’t find so many people ranting about how Servlets suck, web.xml is complex – etc.
Maybe because it is there long time ago and people did understood its purpose. You don’t find many people arguing that working on the Servlet API directly is not productive, and you usually need some framework on the top of it. But yes, the point is that your application will run almost 100% correct on different Servlet containers.
I see a lot of common things in JSF, too. It is specification, it has different implementations and my application works correct with them (OK, I only have worked with 2). And you need some layer on the top of it to be really productive.
IMO, it is good thing that we have standard API because it makes things easer to developers, tool vendors, component writers etc. Also, I do think it is a good thing that JSF is extensible so we have frameworks like Seam or Shale, because not all problems can be solved by comities. Community will give some ideas for future specification versions and frameworks such Seam will drive innovation here. As I heard Howard Lewis Ship is in JSF 2.0 EG, so I hope some good ideas from Tapestry will have its place in JSF 2.0, too.
My point was that comparing the Servlet / webapp spec to JSF is also like comparing apples and oranges. Maybe the former is simpler, does not try to do too much, maybe the guys on the committee did a great job, maybe it was just luck, whatever. There is certainly not so much of a dependence on tool vendors.
The commenters before have already weighed in on this, but a standard that requires non-standard extensions to solve known problems is not much of a standard, is it?
http://blog.interface21.com/main/2007/04/21/what-spring-web-flow-offers-jsf-developers/ for the essence of this support.
This is the first time I actually see Spring guys supporting and defending a bad spec.
George,
In the article you linked to above I am not defending the JSF specification.
In the article I simply outline the fit between Spring Web Flow and JSF, how the integration was done at a technical level, and show some basic examples. The goal was to communicate what Spring Web Flow offers when used as a JSF extension. The article was written primarily for those in the Spring community who have made an existing investment in JSF, and seek to understand how Spring Web Flow fits and compares to some other options in that space.
The JSF specification is not perfect and the expert group has acknowledged that. With that said, I can appreciate that the JSF customers I support have more choices available because the pluggability built into the specification has enabled a competitive market to develop.
Keith
>There is certainly not so much of a dependence on tool vendors.
I really don’t understand why people often say that JSF requires vendor tools. I use JSF with Eclipse + WTP and I really don’t think I need something else. Maybe Facelets support in tools, but currently I am fine with plain XML editor.
>The commenters before have already weighed in on this, but a standard that requires non-standard extensions to solve known problems is not much of a standard, is it?
Standards itself does not mean much. If the standard is bad or if it is not widely accepted than it is not useful at all. In my opinion, if committee cannot give good solution for some problem than it is better to let community to try solve problems than to enforce bad solutions. But it is important that some level of standardization exists. JSF spec has a lot of drawbacks, but since it is pretty open many solutions had arrived from community. I don’t see anything bad in that, especially because many of these solutions are becoming parts of specifications. Facelets are not standard but many JSF developers are using them. But that would not be possible it JSF itself is not a standard. Jboss Seam itself is not a standard but I can use all JSF components with it. This also would not be possible if JSF is not standard.
Anyway, if you are already using non-standard framework (such as Wicket) what is the point of insisting on JSF without non-standard extensions? Do you think it would be fair Ruby vs JavaEE comparison if you would compare RoR application with application written in Servlets + JSP only?
The fact remains that people often say this. Somebody even summarized the InfoQ link to this blog entry as “Bloke who likes to do everything by hand doesn’t like to use tools”.
FWIW my personal conclusion from the very simple example given is that tools will be required when the UI gets more complex. At any rate – definitely more than what Wicket requires.
Completely agree with you on that one.
I never insisted on anything of that sort. I do agree with your point here that standards don’t matter.
There is a saying that a camel is a horse designed by committee. IMO, JSF is that camel and Wicket is the horse.
There is one JSF feature I have not yet formed an opinion about, and maybe others can comment: a simple example like this doesn’t show a real use case for a controller (the C in MVC), which is a feature that is built into both Struts and JSF (in the latter it is embodied in faces-config.xml). Wicket doesn’t really have the concept of a centralized mapping of pages to destinations. Is this a weakness, or is it a feature that is overblown and not used much anyway?
JulianS, I think it’s a feature. My opinion: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/
Keith,
I was referring to your ‘ecosystem’ argument. You were basically saying since there is a good ecosystem around JSF including your I21, JSF is good.
BTW, you are not the first Spring guy defending JSF, but JSF is the first case I see Spring guys defending a bad spec. I don’t think it would have been the case if I21 had a competing non-standard product instead of a complimentary product (i.e. SWF) in this space.
Pingback: A Wicket Diary» Blog Archive » The road to 1.3.0 and graduation
>The fact remains that people often say this.
I have few friends that “knew” that JSF is bad without even using it. Some of them changed their opinion when they actually starting to use it. It seems to me that JSF had bad reputation before first release. It is hard to me to believe that it was based on technical facts.
>I have few friends
It must be that your few friends have never used ASP.NET.
I keep reading how great ASP.NET is. Having actually USED it myself (I wonder how many did who promote it in threads like these) when working on a couple of projects, I have to say I hate it. It’s better than JSF in some ways, but still full of aweful design decissions (like view state and the inability to manage member variables automatically, the default of coding validations in markup, how horribly complex it is to create custom components, etc).
Thanks for the great article.
I think JSF was developed from the ground up with one idea in mind; Allow RAD development of Web Applications in the java world. for as far as my humble experience goes; JSF does a great job.
Using JSF without the proper tool is just not logical. seprating JSF from it’s tooling is just an exageration of how non-logical that is.
I like the concept behind Wicket, I really do. and I wouldn’t even bother to compare it with similar approaches to Web front end design like facelets or tapestry.
Just, please bare in mind that building your example forum plus other real-forum like functionality using IBM RAD, Oracle JDEV, Sun’s JCreator, or NetBeans can really become a single afternoon-snack kinda projects.
The usual mistake I see people repeating while learning JSF is reading so much about it first before actually trying it.
I take newbies, in an hour session using the proper tool and, Puff, they can make web apps. can any one underestimate that?
Please adopt this approach and I think you’d change your prespective: get an IDE of your choice. follow one decent tutorial showing you how to get around with the IDE funcaionality, and then start to build any thing you like.
doing this I found JSF EXTREMELY productive, fun and powerful.
Also, the Ecosystem; I think; can never be overlooked no matter how crappy the original spec some might think.
Did we use Struts? YES! was it fun? NOPE. then why did it grow, simply because of its eco system. from a business point of view I don’t think that any one would underestimate how significant did struts change our web development.
thanks again,
One of the previous commenters was insisting that he manages just fine without JSF IDE support. So who should I believe?
Huh? Are you saying that I should have tried JSF without reading about it first?
Anyone can generate simple aplications quickly using IDE support. But what about complex applications? I think the previous comments tell a different story. Like many others, I don’t believe in the promise of re-usable components, this notion has been proven false time and time again. People expected a component “marketplace” for JavaBeans and Enterprise Java Beans (TM). How many people actually used the “Application Assembler” or whatever role prescribed in the old J2EE blueprints!?
Especially when it comes to user interfaces, I find myself invariably trying to create specialized custom behavior that my application users need – not what some committee decided.
If you think that because newbies initially appear productive because of IDE drag and drop even when they are blissfully unaware of the stuff that this article attempts to highlight, well – good for you. Maybe these newbies don’t even have to know Java.
As for the commenter who does JSF without using an IDE, with all due respect, of course it can be done. but why take productivity out of the equation ? this seems strange doesn’t it.
listen Peter, I’m not asking you to believe me or any body else. believe yourself once you feel you got to the bottom of whatever tool/framework you’re assessing. Every tool/framework has strengths/weakness. and I’m sure JSF/Wicket are no exceptions.
for the reading-first part: I chose to believe that, again, up to my humble experience, reading intro-kinda article only makes people quit learning especially when it comes to a moderatley complicated framework as that of JSF.
What I’m suggesting here is the Crash-course attitude. believe this; it usually turns out to be quite fun. simple, just learn as you go.
As for the market place for reusable components. Java beans is not such a bad example. I’m not an affiliate or any thing but:
http://www.jidesoft.com/ is such a good example wouldn’t you agree.
due to the lack of proper IDE support (THIS is the old mistake my friend) custom components in java never flourished when compared to ancient 14-year old Delphi with “literally” thousands of component libraries (http://www.torry.ru). I wish I see it when it happens to java. but the community didn’t really grasp the beauty of Design by components; at least in due time.
EJBs, I agree, were not logical to be that reusable; but what happened to WebServices, do you think the reusability there + the market place would not grow in time. it’s the business today (the web services day) that is more modular than yesterday (the EJBs day)
I see the problem over and over; after so many years. people still insist on doing things in code and only in code.
One more thought. there is this thing that most people overlook. allow me to say that stateless HTTP is B.A.D bad choice for connected applications. it was never meant to be an environment for application development when it was first conceived.
every tool (or framework, for that matter) that allows web development tackls the devil of statelessness in its own way. but hey; it is Not natural. until we get to a really mature tool + infrastucture that supports R.E.A.L continuity of state. the further we get away from HTML ; I think; the better.
JSF allows this by defining renderkits (you already know) Oracle has a console renderkit. once we tame the stateless infrastucture (or hopefully replace it with something more mature) HTML will go back to what it was made for, content publishing.
And the newbies part. leaky abstraction (I think :) ) mandates that one must know about the ins and outs of his automatable/high level tasks.
having said that; I think again that it’s NOT logical,and, knowing that common things are common; simple things should never be done slowly or painfully; not for any reason I’m buying today.
Sorry for the long post, but this is such a good disucssion.
Wish you the best, cheers.
Maybe you should re-read my blog post.
I think your Delphi example as a success is interesting, (I’m being nice) and jidesoft looks more like an API. BTW if you look at some of my previous blog posts you will find some opinions on SOA / web-services as well.
You do agree that EJB failed in this department. How can you be so sure that JSF will not?
But we digress. Let’s bring the discussion back to Wicket. There are already Wicket plugins in IntelliJ, Eclipse and NetBeans (refer this video interview on the ServerSide which also compares Wicket with JSF). So if you are arguing that JSF is better because of IDE support, I’m not convinced.
But hey, I *do* use IDE support for Wicket – the NetBeans HTML editing support and Java editing support. And that’s all I really need – again, refer to the ServerSide interview. If you want to label me as one of those people who insists on doing things in “code and only code” that’s fine by me. But maybe you should listen to yourself for a moment – when did coding in Java become so uncool.
Thanks again,your post is already nice.
Delphi was a very good example for success, when it was on the right track, but failure to maintain an eco system brought it down. Andres Hejlesberg (former architect of Delphi/VCL) is the one of the people behind the fire of .Net; with a $1M signup bonus;(not that I do like .Net or any thing).
For SOA, wisdom taught: what is not wholely taken shouldn’t be wholely abandoned.
would you say that Struts failed today? just because you and I are not using it anymore?
I’m genuinely sorry, I wasn’t referring to you as “code and only code”, even if it’s fine with you. I really think your post was fair and informative, I meant to only join the discussion.
I hope Wicket even gains more plugins/tooling by the clock, I really do. and then business Developers would really focus on business, not code.
Thanks, I will try to listen to myself more in the future (no offense taken :) ).
Java code is cool, but boiler-plate code is not. what Hibernate did to JDBC is what IDEs are supposed to be doing to manual coding.
Once we both agree to the use of a tool, why settle for a tool that will not go all the way.
Why not just file a JSR for wicket and end the misery, so we; Devlopers / Architects; can have the best of both worlds.
Again I’m not against wicket, I’m merely saying that JSF is a pretty good deal for the time being. JSF 2 is being cooked with people joining in from tapestry. wouldn’t you say this is good news?
Standards are not supposed to be perfect. but they are *just* standards.
Happy development, I wish you the best.
Please use Wicket first before complaining about boiler-plate. And thanks for bringing up the example of Hibernate. Was that a *standard*?
This discussion is just going on and on so let’s just agree to disagree on whether JSF is a good deal. But who am I to try and convince you. Maybe your time will be better spent if you go and comment on the ServerSide at the JSF vs Wicket comparison link I provided in the previous comment – where a real expert shares his opinion and there is lots more dicsussion there.
I’m satisfied with what Wicket offers today (just like I was happy with the “non-standard” Hibernate when it arrived) and I for one am not waiting for JSF2. And perhaps you have heard the saying: too many cooks…
Hi Peter,
thanks for another well-thought, useful post… This is the first truly objectve comparison I’ve found out between JSF and a competing approach.
Even though I’m convinced Wicket’s design is sound, while JSF’s isn’t, I see you’ve used MyFaces to build the JSF example. As far as I know, MyFaces is JSF 1.1-compliant. So, wouldn’t you have got a better or, at least, a different outcome, particularly regarding the generated HTML+Javascript, if you had used a JSF 1.2-compliant implementation?
Thanks again,
Cristina
What if there is a implementation based on JSF concept that allow you create web application without jsp, xml, or even html? Here is the demo
http://socialbase.jot.com/WikiHome/JavaBase/JavaBase%20Download/demo_wmv___118042198754067_89758518399543
Tim
Hi Cristina,
Thanks for the nice feedback. I used the latest available release of MyFaces. I chose MyFaces because I assumed it would be the first choice for the typical someone trying out JSF for the first time.
Considering what you pointed out, and the previous comments on Seam, Facelets etc, does this mean that MyFaces users should seriously consider moving to an alternate implementation?
O.K. Wicket is coole, but how to learn it? There is onli one book at Amazon (Pro Wicket) and that book has bad marks (not for noobs).
Update: simplified the wicket code for the “Create New Forum” form after it dawned on me that the existing POJO is more than sufficient for form binding. See end of the blog post for details.
Pingback: rue’s headroom » Blog Archiv » Guter Vergleich zwischen JSF und Wicket
@Zlatan
The Pro Wicket will get you up to speed. Besides that, the wicket-examples project is very extensive. There are examples for almost everything you normally do in an application, and it includes a component reference that has a bit of explanation for the common components.
Wicket In Action’s first chapters will be available through MEAP (Manning Early Access Program) in a few weeks.
Just a few comments:
as others have pointed out, by using facelets the html markup would be rather similar to wicket:
you would have:
Label instead of
The same applies to JSF 1.2 which allows the mesh of html markup with jsf tags.
As for the dependency example, this is heavily implementation dependend, MyFaces has a few dependencies into the jakarta commons. The JSF RI probably has none whatsoever.
(The same goes for Hibernate with its 18 jar dependency compared to the JPA ri with its none dependency)
As for the application logic, which is left out, this is probably where JSF currently can shine most, as others have pointed out, stateful orm controlling application frameworks can cut down significantly on application logic code, especially orm controlling code, you just work directly on the orm entities and then flush them from time to time without any concerns whether they have to be bound or params have to be passed.
Currently Seam shines most there, but it is heavily JSF and EJB3 dependend, probably more interesting for other frameworks would be apache myfaces Orchestra which is pure Spring 2.0 this has not too many dependencies into jsf (and they have been refactored out and can be replaced. I think every component framework could benefit significantly from getting such a framework. It is basically the same amound of code removal and pain removal as, is if you move from pure actions to a real component framework. But on the backend.
In the end such framework comparisons are more or less pointless because the biggest gripes we currently face are not anymore on the web layer but on the orm and general application layer.
Just my 2c to the otherwise pretty good comparison.
I don’t think application logic comes into the picture at all when you discuss UI frameworks. FWIW, I was originally using [Spring MVC / WebFlow + Spring + Hibernate] and I was able to cleanly replace SMVC / WebFlow with Wicket (you can refer my previous blog post for the details).
I would hate to have a web-framework that dictates how you should layer your application and how you should implement your business logic, but that’s just my 2c.
M$ created ASP.NET so that their massive investment in re-usable generic components (and those of its partners) would let semi-skilled developers accomplish a great deal of simple work. There are many businesses with simple needs hoping to rely upon moderately skilled developers, and M$ hopes that ASP.NET will induce such businesses to license IIS and Windows for their webservers.
So as not to turn this entire market over to M$, Sun created JSF as the Java version of ASP.NET. Unfortunately, JSF component libraries will never be very good as those of ASP.NET because there is no one with the monopoly power to spread the cost of component development among a huge base of users. And that cost is quite high, as building components for the ASP.NET / JSF paradigm of web development is quite laborious.
Perhaps other open technologies (PhP, Ruby on Rails, etc.) will let unsophisticated users build web applications for non-Windows boxes, but what about web developers who _want_ to use a Java-like language and who prefer Java to C# (either because they’re more familiar with Java’s libraries or because they simply don’t want to join the M$ camp)?
If there is to be a place for Java on the web, it has to take advantage of the J2EE world’s strengths, rather than competing with M$ on its home territory. We can build on the strength of the J2EE world by adopting the reverse strategy. Instead of making it easier for novices to _use_ pre-existing components, Java should standardize on a framework that makes it trivially easy for object-orientation experts to _create_ their own reusable components to do the less routine tasks — tasks for which satisfactory pre-built components are unlikely to exist even for users of ASP.NET. It should be a framework based on components that are easy for the intelligent developer to specialize with new capabilities.
I think Wicket is the ideal web framework for this strategy. I don’t know any other component-oriented framework in which it is easier for object-orientation experts to create new re-usable components or to specialize pre-existing components by adding functionality. This approach weakens the advantage of M$’s monopoly power, and provides an advantage that M$ cannot match (at least not until a C# version of Wicket is implemented).
And if someday IDE plugins can be developed that make Wicket easy even for unsophisticated users — so much the better!
Pingback: Wicket user try JSF « Khi công việc yêu cầu phải học Java :-)
@Werner
Wicket now has initial support for Seam as well. As for cutting down application logic… well it depends whether that is desirable. If it means replacing statically typed Java by a bunch of strings (like EL expressions in your view layer that connect to global names of your business modules: no thanks :) You actually get something for this verbosity (Java): better code navigation, help with refacoring, API discovery, etc.
hi
you have to check JSF with JDeveloper
JSF is a component oriented framework for building web components.
a component framework should be used in tools, and tools like JDeveloper, Netbeans with Webtoolkit (Java Studio Creator), Exadel Sudio make correct use of components.
in pure JSF form developers don’t need to learn and see the HTML and JSF markups they will only work with JSF components.
cheers
Arash Rajaeeyan
>Perhaps other open technologies
>(PhP, Ruby on Rails, etc.) will let >unsophisticated users build web
>applications for
use plain JSP custom tags (like Coldtags suite http://www.servletsuite.com/jsp.htm) and stay in Java
jsf reminds me a lot the ejb1.1, it is destined to fail… it is trying to control too much: managed-beans, navigation-rules, 6 phases, complicated events… it is not flexible, not pure OO… i want to fly but ejb and jsf keep drag me down to the ground..
i wonder why nobody mentioned silverstream, in my mind they are the first one who developed a component web model, they even have a UI tool to drag and drop the components and god it was in 1999! how slow the java web evolution is…
i also used another component framework a lot like wicket in 2002, it is html template plus pure java, each page has its own controller, which in initial time intialis all the controls/components in the template page, then at flush time loop thr’u all controls to generate the output…
to me the real cause of all these is xml… it is way too much blown out, either by form of webservice or DI or ejb descriptors… the best is pure java, although java itself is a bit too static not dynamic language, that is why AOP comes out…
You should consider also the click framework which, in my humble opinion, is even easier to code in than Wicket.
Please do review click when you can.
http://click.sourceforge.net
Pingback: Wicket Impressions, moving from Spring MVC / WebFlow « Incremental Operations
Excellent article! I agree that JSF is over-complicated, requires too much time to learn and definitely not-intuitive. Wicket is much better.
Hi Peter,
would you please post the code of the 2 pages as text files, just the html and java pairs? The files will surely be a helpful starting point for all those who are building their first Wicket app.
Thanks so much,
Cristina
Hi Cristina – I just uploaded the files you need as plain text at the end of the post. The Wicket web-site has very good examples you may want to look at as well.
JSF against other web component models.
Hi all, may be JSF is not best web framework, but
1) it is standard
2) there is good tool support for it.
<> it is a bad standard, but as long as those good frameworks you name don’t have good tool support they are not useful for any one.
Arash, I don’t think you have read any of the previous comments :|
the problem with wicket is, not done, just want to build a datagrid takes a lot of pages. Want to do this, oh cannot since the framework is not done yet and a lot of bugs. what is wrong with that? at least asp .net is more stable and build datagrid really easy. what’s is wrong with wicket still complicated to understand especially uri error..i hate that
and try to find support to learn wicket. Good luck, waiting..and waiting..and waiting….
Sorry “gogo”, as someone who has used Wicket to build a reasonably complex application, to me it sounds like you have Wicket confused with some other framework :)
But I don’t think your comments are meant to be taken seriously. In case they are, I completely disagree with your comments.
Ok show me side by side the code of datagrid using wicket and dot net
i would like to see the code.
sorry, don’t know .NET
Pingback: 59 23 * * 0 flush » ההתחלה
Pingback: Wicket vs JSF, Forum Application | The "Break it Down" Blog
This is the first example which is “not too much, but just enough”. Could be presented to e.g. a “low tech” manager with the words “… and this is why we shouldn’t use JSF”.
Now I wish someone had such a simple Wicket & Tapestry comparison. [If I missed one, thanks in advance for the pointers :) ].
Pingback: it-fabrik blog » Blog Archive » Comparing JSF / Wicket
What about the seperation of concerns between application developer and graphic designer?
Exposing a JSF bean that contains a list of Forum objects appears to give the graphic designer (assuming he understands the concept or repeating something) more flexibility than building the table in Java.
There’s nothing wrong with putting logic in the display if it relates to how the designer wants to display the page.
@bravocharlie
>> “There’s nothing wrong with putting logic in the display”
Oh come on. And you assume that the graphic designer is Java aware. And JSF tag aware. And JSF-EL aware. And is smart enough (or has tools smart enough) to not mess up the logic by mistake when tweaking stuff.
Let me try another example. Suppose you need the rendered table to contain some merged column or row cells (colspan / rowspan). Try getting your graphic designer to do that in JSF. Still feel you have more flexibility?
Pingback: Project template wicket-spring-hibernate
You know, counting up the lines of code, there are exactly 7 lines of code difference between the two (140 vs 147).
Furthermore, looking at the jars for the libraries, there is only 194 K (10%) difference between the two since the Wicket Jar is a whopping 1.5 meg while the myfaces api (correctly) uses other libraries for functionality resulting in a larger number of smaller jar files.
Hardly much difference.
@Andy
Nice try :) Nowhere in the post did I use
a) number of lines of code
or
b) size of jar files
… as a comparison point. But thanks for pointing out that Wicket is better in these areas as well.
Well, not quite better. Most of the JSF stuff is one time setup code while most of the wicket lines come from the actual content such as pages which will grow as your application grows.
You compared jar sizes, number of jars and the amount of code required as a comparison point :
“…Wicket does not require any extra XML config…”
“…the contents of the Jetty “lib” folder come down from 6.16 MB to 692 KB…”
“…Wicket does not require any kind of XML configuration…”
“…MyFaces requires far more dependencies than Wicket i.e. 10 vs 4 JAR files…” (yes, because it bundles it all in a 1.5 meg jar!)
So what you are saying is that Wicket is good because it doesn’t use an xml file, and we can just ignore the fact that it gets replaced with java code on a per page basis. Seems a little disingenuous if you want to cherry pick your comparison points and claim you are not talking about lines of code while throwing phrases like ‘verbose’ against jsf.
I started playing with Wicket a while ago. I like the concept for the most part, and think it will benefit those with good OO design skills who can use inheritance to great effect.
However, I find it extremely verbose writing HTML and some java code for each control I want on the page.
Look at the listview vs. a dataTable for example, anyone can look at the code for displaying a dataTable and see what is going on. The listview? Well you need to look at two files to see what is going on, but it is far from straightfoward.
Facelets provides great templating and is now a part of the JSF spec. In wicket, I can’t see any way to perform templating so I can have one page where I lay out the headers, footers and content position and just re-use that in each page without having to duplicate the layout per page. I’m sure it’s there, just not obvious.
I’m a big component framework fan, I’d have Wicket and Seam as my top two over action based frameworks. I’m also looking forward to seeing what the Seam folks do with Wicket integration.
Again, I never used amount of code as a comparison point. If you want to twist my words around and claim that “no XML config” means I said “less code” and then use this to accuse *me* of being disingenuous and “cherry picking”, then be my guest. Turns out that the Wicket side has less lines of code anyway.
Wrong. Your faces-config.xml will also grow when your application grows. And what’s worse, you have to synchronize things like navigation rules with your new Java code and your new templates. The fact that you use string expressions to drive navigation (e.g. return “home”; / action=”create”) makes it really brittle and type-unsafe.
Here I am clearly talking about the count of framework dependencies and you accuse me of using size for comparison. But even if we consider size – Wicket is better! The point is – some people (like me) prefer to reduce dependencies on external libraries.
I’ll let you in on a little secret, by mistake I did not include the log4j jar on the JSF side – but I have it included for Wicket. So you can do the math again :)
This is the footprint for the application-server not the framework. The point? You don’t need JSP and you can embed a web-app server within 1 MB with Wicket (which I do currently in a project). The fact that you ignore most of the comparison and cry foul on the relatively trivial sections on footprint / framework dependencies (still failing to prove that JSF is better) really does say something IMHO.
Wrong again, Facelets is not part of the JSF spec.
Actually this is a core feature of Wicket (not a bolt-on like Facelets) – take a look at “markup inheritance“. In addition, there is native support for compositing components into panels. Panels are how you can easily create custom components in Wicket – something comparatively harder to do in JSF.
Maybe I will post another blog entry with advanced examples like this but for a more complete list of comparison points for Wicket vs JSF you can look at the last slide of this presentation I made recently.
Pingback: From The Web : à propos de Wicket… | NooCodeCommit
When using seam in example why have used JSP ?? You could have used xhtml …isn’t it ?
Pingback: Wicket and GWT compared with code « Incremental Operations
I think wicket is really cool and we use it occasionally on projects. However, to me, there are two main draw backs.
1) To me, mixing ui and pure java code is a bit obscene. I feel bad every time I need to put some javascript or css in Java code.
2) It’s by far, much more verbose to write than all other frameworks. Lines of code is not a really good comparison, but all the new Component(“id”,view,otherParam,anotherParam) { inne code}; and so on. If you have costumers with some requirements that don’t follow “the standard way” you’ll be in a big mess of code. Just try to have a ajax-link that toggles checkboxes in a 3×3 table..
Pete Muir has converted “The booking example” for Seam from JSF to Wicket. If you remove the explanations that only are present in the JSF example, you get the following line counts.
WICKET
———————-
java: 1965
html: 570
xhtml: 0
xml: 309
properties: 52
wsdl: 0
css: 422
———————-
Total: 3318
JSF
———————-
java: 1486
html: 4
xhtml: 785
xml: 429
properties: 52
wsdl: 0
css: 422
———————-
Total: 3178
And I promise you, the JSF code is much simpler to maintain and understand in this example.
Hi Daniel,
You are a committer for Seam, right? Anyway.
Sounds like you haven’t used Wicket at all. You can look at this comparison with GWT that shows how Wicket does Ajax without you having to write Javascript and how the CSS stays out of the Java code.
This blog post proves you wrong with respect to JSF. And see the link to the comparison with GWT I posted above. By far, much more verbose than all other frameworks eh? Yeah right.
Its funny that you say that “lines of code is not a really good comparison” and then post a whole bunch of line counts :) Anyway, your numbers prove that if you want to program in XML instead of plain Java and HTML, you might be better off using JSF.
Thomas: Correct about Seam. I haven’t used GWT enough to evaluate it. yet.
What I meant by mixing, I’ll give an example. How to dynamically have a certain class on a specific row in a list (depending on the state of the content of the row).
In wicket it would be something like
someComponent.add(new SimpleAtrtibuteModifier(“class”,(object.isDelayed)?”red”:”white”));
I think (and this for sure is a personal preference)
<h:outputText … styleClass=”#{object.delyed?’red’:’white’}”
is a much better seperation of ui/businesslayer. Specially since the businesscode in wicket will be nested in the same component’s form’s “onSubmit”. But again it’s a preference.
My comment ‘lines of code is not a really good comparison’ was an excuse for myself for using line count as comparison. Neither my line count, nor your article, will have any great impact on wicket vs. jsf anyhow. Your end statement earn a lot respect. Some fan boys (on either “side”) would never have said something like that.
With first class wicket support in Seam, and your talent for making comparisons, couldn’t you create an “jsf vs wicket, using same middle/back-tier” comparison?
Cheers
Pingback: IT pro life
please post the page about text twist together with the codes.
Pingback: JSF sucks « Incremental Operations
Pingback: Atanas Roussev – J2EE, Java Developer, UI Engineer, Resume – Vancouver » Blog Archive » Java web frameworks
Pingback: Альтернативы JSF для Seam | Alexander Shchekoldin "all in one" blog
Pingback: Confluence: Intern: Developer
a refresh with jsf 2.0 would be wonderful!
Hi Peter,
Looking at wicket reminds me of Tapestry 3 days. It uses a very similar approach and one that I have been looking for in all the popular frameworks today, and that is, separation of logic from the UI. Dont know why Tapestry digressed from this approach in their later versions.
Anyways, thanks for the excellent review.
Pingback: Forum List | AllGraphicsOnline.com
JSF2.0 is significatly easier to use than JSF1, a lot of that XML has been binned and replaced with nice simple annotations.
Wicket v JSF is a pretty even match IMO, I have tried both and can’t really say I have a prefered favourite now.
I was interested in your “So I tried Spring MVC” comment, how was that for you? JSF or Wicket v the view layer of SpringMVC must have been a no contest. I tried SpringMVC once and found it horrendous… Never again!!!!!
It’s very outdated, but I simply loved the JSF x Wicket comparision! You made me a “jsf-user-tries-wicket”. :)
I am trying to choose btw JSF, Spring MVC/Webflow, Wicket for 2 small/mid size enterprise projects with online booking and payment system. May also consider GWT and ZK.
As a beginner in java web apps, its rather confusing.
How about a more current comparison now with JSF2, Spring 3, and Wicket??
Spring xml configurations and numerous files are a turnoff.
JSF online tutorials seems easy, but oracle official tutorial has too many pages.
Wicket appears easier, but has limited components?!? Correct me if im wrong, wicket server side ajax can be an issue in responsiveness. Its stateful design maybe (since everyone seems to be going restful) or may not be an issue (good for security).
GWT seems most natural for client app, thou it comes with non-std design practices and limited (ugly) widgets and especially animations.
Can i use JSF, Wicket, Spring with standard Wysiwyg designer? Its good to separate UI front and server backend development, so that my company sales guy can help do UI design and present it to customer directly.
Min coding and configuration is important too. Productivity is.
It should be able to use Jquery (or other js libs) easily too, so as not to be limited to its own components/widgets for animations.
It will be a great if someone can help clarify above doubts?? :-)
perfect article on wicket technology
Pingback: Confluence: External Projects
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
Reblogged this on lava kafle kathmandu nepal.
Pingback: Confluence: Product Info
Pingback: Confluence: Product Info
Pingback: badtameez dil video download
Pingback: free download lagu tak akan ada cinta yang lain