Ok can we all ignore the troll and go back to the original subject... Like Craig pointed out Rick, I think you should play around with JSF first and then Shale. The IBM serie "Cleared FUD about JSF" is a good introduction to. I think one of the previous poster posted the link.
Shale is decomposed in modules so it not so hard to get a grab on the functionalities, one type at a time. Actually, it's not very complex except maybe the Clay plugin wich does require some time to understand but using it or Facelets instead of JSP is worth the troubles in my opinion. Anyway, I have been playing with JSF for sometimes now and here's the various differences against Struts I've found : - ActionForm and Action (more Dispatch Action in fact) are replaced by backing beans. No more copy between ActionForm and Domain objets or data transfer objects are necessary. -The event model is fine-grained instead of coarse-grained. In struts, you don't have a true event model and the only event is receive a request and the *listeners* Action, are application wide. In JSF, the basic event listener are registered on a single component instead of the complete application. You have two basic different events (ActionEvent and ValueChangeEvent) and the event listeners all receive an event object representing the event context. Plus, in JSF you can register more then one listeners on a component so no need for Action chaining and the troubles coming along with it. Note that the action events listeners are not responsible to choose the next view like the actions are in Struts. It's quite a change but you get used to it very fast in the end and this way your backing beans (most of the time, they are the action listeners) are easier to reuse. Overall, you can understand this quite fast if you are use to program Swing applications. - The binding mechanism is way more powerful then Struts one and I think this is where JSF really shine. In struts, you could only match form beans properties to forms html tags and it was complex to bind complex forms. In JSF, you can use EL value bindings or method bindings expressions. It is really great in my mind and very simple at the same time, thank to IoC and managed beans. - Finally, JSF has a component model and so reusing is very easy. The components hide most of the complexity to the developper (ugly javascript for exemple). Learning to developp components is what take time to learn, but you can get started quite fast if you just want to use it first. At least, there are a lot of exemples available. - One last thing, since the data and method bindings are specified in the "jsp/html/whatever technologie you use for view" page and the navigation is specified globally in the configuration file (not per action like in Struts), it is quite easy to follow the application flow. It was something that was annoying me sometimes with Struts, lot of places to look to find where the executed code is located. I hope it's help and since I am far from considering me a JSF expert, anyone can feel free to correct me. And please be tolerant about my english since I am not a native speaker and it's quite a long post :) On a side note for people having experience developping custom components, what annoys me so far in JSF is the model package, in fact the SelectItem class. There are no model objets for action components (like you need for a menu or navigation panel) and no universal components (UISelectItem and UISelectItems) for specifying the model. You need one for each component and it is quite a pain in the a.. to code those again and again. Anyway, it always possible to develop your own model hierarchy and use an adaptor to make SelectItem compatible with it. As anyone had the same problem so far? If it is the case, maybe a solution could be part of the future commons-jsf package that have been discussed in the past. I am working on something around this problem so I could probably submit it once I'm done. On 1/7/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > LOL I gave him the very same answer that you did, including the same > citations. The difference is that I did not gloss over the confusion you > have systematically engendered by not just owning up to the differences from > day one. You don't have to love something to explain it. Otherwise, who > would have known about the ugly duckling? > > On 1/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > > > > If you are familiar with Core J2EE Patterns terminology, you'll find it > > easiest to understand JSF and Shale in terms of the View Helper[1] > > pattern, > > where the helper items are the JSF component tags and your backing beans, > > and the Dispatcher View[2] pattern, which combines the Front Controller[3] > > and View Helper[1] patterns together. In the Dispatcher View sequence > > diagram (Figure 7.25) the roles and responsibilities match up like this: > > Don't expect much help from someone who doesn't seem to care much for > > either > > JSF or Shale :-). > > > > Mark > > > > > > Craig > > > > [1] > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html > > [2] > > > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html > > [3] > > > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
