Components: JSF & Tapestry vs. WebWork
Every time someone tries to tell me JSF and Tapestry are superior to WebWork, they claim JSF and Tapestry have one advantage: they're "component oriented." What does that mean anyway? Mike's presentation (PPT) from two years ago (when WebWork 2 was still in beta) cites "componentization" and "reuse" as two of WebWork's goals. Does a framework need superfluous XML and boilerplate code to qualify as "component oriented?" I would say emphatically, "no." Maybe the JSF camp counts writing more code to enable tools as a virtue? I'd just assume do without the tools and the extra code. From my experience, WebWork supports "components" quite elegantly with minimal coding. I used to think I was missing something. Now I'm starting to think the JSF and Tapestry proponents are the ones that don't get it. Which is it?
2 Comments:
Much of the commentary on the relative merits of the various web frameworks can be taken with a grain of salt. To play around with any of them is easy; to really get to grips with one of them takes time and at least one decent-sized project. The number of people who have gone this far with several frameworks are few and far between, so the commentary frequently just translates as "the one I use is the best". That said, I have used the above three and would have no hesitation in saying that Tapestry is the most demanding to learn and also the most powerful. You use quotes around the term component-oriented as though it was some kind of marketing buzzword. It's not; it's a clearly understood term. It means that, as would be the case with (say) a Swing UI, the components you see in your interface (all the buttons and textfields and so on) are represented by objects in the application. The really important thing here is that these are regular stateful objects. The reason that the action-oriented frameworks are a step backwards from an OOP point of view is that they invariably incorporate the central notion of a stateless object that performs one operation (i.e. services the request). That might be defensible if there was a Strategy pattern involved somewhere, but without that, it's effectively just a step back into the pre-OO dark ages, programming-wise. People attempt various forms of reuse with the various frameworks. They might even go so far as to refer to the reusable chunk as a "component" (with a certain amount of license). But the appearance of the term "componentization" on a PowerPoint slide does not in any way make WebWork a component-oriented framework. It's unambiguously action-oriented. I mean, take the following class name from the slide:
AddPet.java
(I don't think this requires any further comment.) One final point is that some problem domains are inherently action-oriented by their very nature (or more commonly, some areas of a given problem domain are). Tapestry covers this effortlessly as well. You write what is known as a service, which is much like writing a servlet. Bingo! You have switched to action-oriented Tapestry. (Within an application, with almost no effort.)
I think you're in denial. So the only difference is a component has state? Where does tapestry/JSF store this state? The session? What happens when you open the same screen in two different windows? Do they share the same state?
If you want state across requests, it's trivial to tweak WebWork to pull your action instances from the session instead of creating a new instance of each request, but then you have to worry about concurrency. How does JSF/Tapestry handle this? Synchronization? What if an event takes a long time? If so, the user can't make any more requests until the first one completes.
So far as the "AddPet" action, you need some sort of construct to bind together your components. Tapestry and JSF both use XML. I'd just assume use a class. In WebWork your action can be a simple container for components. For example you could reference one or more DateModels, TableModels, etc. The view templates would parallel this structure (i.e. DateTemplate, TableTemplate, etc.). What more does the complexity of JSF/Tapestry buy you?
Also, who are you?
Post a Comment
<< Home