Just so you know, Alexandre Poitras, and others with similar tendencies, calling someone a "troll" in a professional setting having to do with their occupation almost certainly is an actionable per se libel with presumed damages and linking the person doing the libel to any and all jurisdictions covered by this list. This is not a chat room where idiocies and loose talk are the common fare. This is a professional setting. I would keep that in mind if I were you. This is not some free-fire zone where you can treat people outside the law. If you have your opinions, that is well and good. Don't negate mine with statements like this unless you want to have to prove the matter in a court of law. This is made public rather than to you personally to give other similarly lacking in enlightenment fair warning. Sorry to have to discuss something other than the issues.
On 1/7/06, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
