Sunday, December 16, 2007
WebBeans, the JSF cover up
At JavaPolis I saw very good presentation on WebBeans by Bob Lee. Bob did a very good job in explaining the concepts while thankfully still giving lots of code examples. WebBeans provides a way to use ordinary Java beans in the JSF environment. You do this with annotations.
Praise for WebBeans, and its main predecessor Seam; they really make developing JSF applications simpler. In particular, the conversation scope is a brilliant invention. But how simple does it get? Well lets see. For every aspect that can be managed there is an annotation. In one of the presentation examples I counted about 5 lines of ordinary Java code plus at least 12 annotations! Now there are ways to group annotations, but you do this by introducing more annotations! So instead of having to deal with JSF stuff, you now how to cook annotation soup.
I have always hated JSP programming, and now that I see that even talented people like Bob Lee and Gavin King are wrestling to fix JSF, I finally know why. The problem is that the whole idea of having contexts to store page data is flawed. It breaks all kinds of encapsulation rules and breaks the beloved type safety.
So what are the alternatives? Actually there are a few very nice web frameworks that do not use contexts. The one I am most familiar with is Wicket. Another often named contender is Tapestry, but of course there are many more. Wicket, like Swing, uses a component tree to build pages. Each component is completely responsible for its own markup (html) and data (the model). No encapsulation rules are broken. Another addition is GWT, not exactly a web framework, but nevertheless useful for making componentized web applications.
Subscribe to:
Post Comments (Atom)
Ok, so why is using a page context flawed, or breaking encapsulation? Please go into more detail. Doesn't working with a form bean (with getters and setters for fields) satisfy encapsulation?
ReplyDeleteThe general consensus is that when you are dealing with a form, a page-based framework is best, but when dealing with a rich interface, a component based framework works best.
I kinda agree with Anonymous above in the sense that you not really define what you mean with the page context(I can gues here since you commenting on type loss.) and whats really so bad about it. as you mentioned examples always make a nice addition here.
ReplyDeleteAnonymous, are you saying rich interfaces can't have wizards/forms Since I think that they are not mutually exclusive, I'm gonna hit at that you can also have a wizard/form component, but this is getting offtopic i think.
JSP was intended as a scripting kinda thing and as scripting goes staticly typed stuff doesn't mix.
So your not a scripted well me niether. ppl from the design department seem to be a different breed.
Are you 100% sure you need JSF?
ReplyDeleteWhy not stick to a good, full-stack, ridiculously simple and efficient action-based web framework like RoR or Mentawai?
http://www.mentaframework.org/