On 3/15/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I see more books about JSF that were published in the three *months* after > 1.0 went final than in the three *years* after Struts 1.0 went final (and > that takes some doing -- Struts got a *huge* amount of coverage).
Most Struts books paraphrase original documentation anyway, do not discuss real-life problems and non-standard practices. By and large they are no better than original docs. > I see credible efforts from multiple parties to create JSF based component > libraries ... orders of magnitude more successful than JSP was ever able to > get people to build tag libraries. Because people could not cook JSP properly. Currently "JSP sucks" motto is almost as popular as "Struts sucks", especially with Tapestry and Wicket crowd. Those who still use JSP insist on using parameterized tags instead of includes. Why? Because it is "better". It is the "proper way". Because it is the official recommendation since JSP 1.1: http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeView.html Why the recommendation? Because JSP designers treated JSP (and still do) largely as pure rendering technology: http://java.sun.com/developer/technicalArticles/J2EE/jsp_21/ You can take a look at what happens when dead rat is pulled out from the stew: http://jspcontrols.sourceforge.net/ Fellow JSP developers blindly followed the path lit by Sun, just like fellow Struts developers followed (and follow) ancient mantras, like "storing state in session is bad", "dispatch actions are useless", "page is the center of interaction in Struts universe, and a pair of setup/submit actions are just servants", etc. > I see better tool support for JSF than I see for Struts. Again, *months* > rather than years after the 1.0 release. Because, thanks JCP, JSF official specs *are* specs. They are easier to follow and implement. Most people follow the official standards and practices very closely, so JSF is better for them. For example, the most sucky part of Struts is de-facto String-only ActionForms and thus need for manual conversion. Solved with FormDef. But most people do not want extensions, they want "original product". JSF is a way to give an original product to them, in countless reincarnations. People can hear only one shepherd at a time, Jesus knew it like no one. > Compare the MailReader app as > implemented with Struts and with Shale+JSF. Craig, can you help with the link to Shale Mailreader, could not find it. > Compare the (upcoming) > implementation of the iBATIS JPetStore application (implemented with Struts, > but with a "dispatch actions" hack) Who's making it? iBatis guys? I am interested, I am fond of "dispatch action hacks." > * If you are starting a new project, you owe it to yourself to evaluate the > benefits a component > oriented architecture can bring to your application. If you don't know > that those are, shame on you :-). I agree that a component framework has its benefits. But with upgrade from Struts to JSF why not to upgrate the whole platform including OS? JSF is a component framework. JSF is not the component framework. There is no upgrade path from Struts to JSF, even JSP pages are different. The fact that JSP is now regarded as "that crusty stuff we brought with us to make show that JSF provides backward compatibility" does not make JSF more appealing that other component frameworks. Oh right, JSF *is* a standard. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
