>From: Dakota Jack <[EMAIL PROTECTED]> > > 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.
Actually, I've always thought of this kind of troll http://www.pitt.edu/~dash/type0122e.html >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. > Very interesting, and only if as much intellectual collateral was spent addressing technical issues... > On 1/7/06, Alexandre Poitras 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 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 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~ >
