The problem is not SEAM, it’s not Wicket, it’s not even JSF, the problem is you’re a retard.

This “case study” (perhaps the word “comparison” is what you find offensive :) uses the *official* “Hotel Booking” example code – which Seam committers and evangelists have been using for a while to show off the features of Seam.

So pardon me for putting the question back to you: Get it?

I’m not to the “no accounting for taste” point yet… There’s an important point here that I’m not sure you’re grokking. Maybe you are. I’m just not sure.

For me it IS the wrong comparison. I would not use Wicket by itself, as I get too much value from (in my case) Seam. From your numbers I don’t know what the performance impact is of using Seam is as I’m not using JSF/Facelets/Richfaces but instead I’m using Wicket.

So far, I think what you may have demonstrated is that JSF/Facelets/Richfaces is slower than Wicket. Great! I much prefer Wicket to JSF/Facelets/Richfaces. But for me, that’s the comparison. I could use Wicket by itself, but it’d be a lot more work. Why would I do that w/o knowing the perf impact?

Get it?

Ian

The Wicket side of the comparison is just Wicket + Hibernate (JPA). Nothing else. No Spring, no JSF, no Facelets, no Seam, nothing.

If Wicket can replace Spring, Seam, RichFaces / JSF and Facelets at the same time, and give much better performance – I personally find the results of this comparison interesting and very useful, and so do many others.

It’s a pity that you say “it’s the wrong comparison”. But to each his own, I guess :P

It’s more like wicket vs. JSF+Facelets and/or Spring “vs” Seam (although Spring and Seam can be used together). If I were thinking of replacing a lot of the services I get from Seam (and I’m not), I would likely look to Spring. It seems to me that they are both most useful for knitting/injecting things together and for making powerful technologies easier to use.

I might look to wicket regardless as it works nicely with both Seam and Spring. It’s true that the Seam documentation is JSF heavy/biased, but I think that has more to do with timing. The core of seam has little to do with JSF/Facelets; it just has great support for JSF/Facelets. Seam now has very good support for Wicket (the core annotations work and their are wicket specific annotations and a seam-wicket.jar in the distro). I would also expect to see greater support in the future (e.g., seam-gen support would be killer or, perhaps better, support for wicket/seam in the wicket maven stuff).

Seems like Seam has a wrap as being heavier than it actually is. I think that’s because it has great support for a bunch unwieldy technologies. For example, it has elegant support for all that big fat JavaEE stuff and can make that rather large pill easier to swallow. But you can use wicket/html/pojos plus Seam pojo annotations and access most of the best parts of Seam in a super-elegant lightweight fashion with almost no XML.

With regard to JSF/Facelets versus Wicket, for my part, JSF/Facelets at first seems attractive from a DRY perspective, but in practice I find JSF/Facelets restrictive, unintuitive, and byzantine. Plus, simple stuff is way too hard in a guess-what-I’m-thinking sort of way. Maybe I just don’t get it yet — entirely possible.

cheers, uwe!