On 3/15/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Growing like wildfire? Hmm... well, I'm certainly not intimately > familiar with that community, so I can't argue that point.
If you believe that, nothing I can do will persuade you otherwise. I'll just leave you with my personal belief ... MyFaces is very close to knocking off Struts as the second most popular Java-focused Apache project (after Tomcat) by every measure *I* can see. And I talk to *lots* of developers over time -- not just the few that pay attention to the Struts mailing lists, and the overwhelming question I get *used* to be "which do I choose, Struts or JSF", and in the last three months it has turned into "what's my migration strategy?" 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). I see job postings that used to be 80/20 "struts and everything else" start to be 30/30/20 "struts/JSF/everything else". 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. I see better tool support for JSF than I see for Struts. Again, *months* rather than years after the 1.0 release. And, I see a pretty significant backlash against Struts *because* of our emphasis on backwards compatibility. Hopefully, SAF 2.0 (the result of the WW merger) can put that crap to rest -- but I've gotta tell you ... if Struts developers hadn't been so passionate about backwards compatibility, it would have *never* seen the early adopters that it saw. Tell me that was a bad thing. So what are you seeing? Or are you just seeing things you wish were true? Legacy doesn't count in this equation -- *of course* if you have existing apps based on Struts you are going to be pretty passionate about ongoing support. And for those folks, the activity around Struts Action Framework and the WebWork merge is absolute goodness. But it's time to stop being an ostrich, and understand that JSF is *already* here to stay. You seem to be one of the repeaters of the "JSF hasn't lived up to expectations" mantra. *Whose* expectations are you talking about? Your perception of this certainly does not match my experience over the last couple of years. Craig PS: By the way, with Shale's support for Commons Validator and Tiles, Shale+JSF can legitimately claim functional equivalents for everything Struts 1.x can do out of the box. And many of the Struts add-ons being bandied about are simply not necessary in a JSF world, because JSF's controller already deals with those issues. Don't be misled by people who think that the programming environment -- for the *application* developer -- is subtantively different, either. Compare the MailReader app as implemented with Struts and with Shale+JSF. Compare the (upcoming) implementation of the iBATIS JPetStore application (implemented with Struts, but with a "dispatch actions" hack) to what you can do with JSF, with fewer/simpler Java classes. The interesting message I am seeing is this -- the internal architecture of the framework doesn't matter much to everyday use of that framework ... the "shape" of the resulting application can be basically identical in both paradigms. PPS: As you might imagine, the most popular question I get asked when I speak at conferences related to web architectures is "what do I do now?" My standard answer goes along these lines: * If you have existing Struts based apps, don't feel threatened into being forced to move. Struts Action Framework will take care of your needs, and has a clear roadmap (with the WW2 merger) to make your life better. * If you have existing Struts based apps, but need some of the benefits that components can bring you (but also don't have time to migrate an entire app) ... no problem. The Struts-Faces integration library allows you to transition from one architecture to the other, one page at a time, althougth this is not an optimum long term architectuire. But it means you are *not* stuck having to convert your entire app at once. * 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 :-). Note that there are no functional limitations ( i.e. things you can do in an action oriented framework that you cannot do in an appropriately architected component framework), so the key decision point needs to be whether you can benefit from components or not. Opinions that the underlying architecture of the framework really matters to anyone beyond framework geeks needs to be *seriously* questioned :-). * If you need to transition from Struts to a JSF-based architecture, it is much less painful than you might be led to believe by the currently popular FUD :-). And, as an added benefit, transitioning from what's likely to emerge from the WebWork merger into Struts Action Framework 2 is going to be even easier :-). The WW2 concept of an action class, and the JSF notion of a backing bean, are virtually indistinuishable. The only substantive differences are in how you customize the overall framework behavior ... and that is more in the "how do I do it" details, rather than "what can i do."
