Good Lord, Alexandre! Do you know anything about the history of JSF. On 12/13/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > I think JSF will succeed because it was not designed by experts in a > meeting room. They looked at what was already available (Tapestry, > Struts, ASP.net) and took inspiration of it. > EJB3 is going the same way by looking at Spring and Hibernate. I think > the JEE world learned is lesson : let the open source organisationand > private corporations experiment new things then standardize an API > based on the existant code, so people can avoid any vendor lock-in and > it allows more then one implementation of the same API. > > On 12/13/05, Preston Crawford <[EMAIL PROTECTED]> wrote: > > > I don't know what the future will hold. JSF may win the day on > nothing > > > but marketing alone. It has the force of being a "standard", and > while > > > not all standards ultimately succeed, it certainly is a leg up on > other > > > > I would argue that with Java (J2EE specifically) "standards" have > largely > > just "emerged". Think of all the examples. > > > > Tomcat > > Ant > > Struts > > JUnit > > Hibernate > > > > That's, by and large, the "standard" J2EE toolkit. And by that I mean > that > > while we may have WebSphere, Tapestry, Maven, EJBs, etc. there's a > certain > > concensus out there and the tools in the first list are what have the > > mindshare now. > > > > So my point of interest is this. JSF, from what I'm seeing here > > (especially when the actual developers of Struts talk about their > reasons > > for jumping to JSF) and reading elsewhere is actually succeeding IN > SPITE > > of the fact that it's not sitting in the OpenSource non-standard seat, > as > > Tapestry is. I find this interesting. It was bound to happen eventually, > > that one of Sun's reference implementations would actually become a > > standard. I know, EJB is a standard. But look how many people have been > > abandoning that in favor of more lightweight solutions, once those > > solutions presented themselves. > > > > So I think the fact that JSF is getting traction IN SPITE of the fact > that > > it isn't quite as open, hasn't been open sourced as long as Tapestry, > etc. > > is a testament to the fact that developers appear to like it. I just > > wanted to know (and you all have been immensely helpful in this respect) > > if you could get done with it, what you can with Struts. Thus the > question > > wasn't "Is JSF better than Struts?" The question was "Is JSF ready?" > > > > And that is the question for me. I know what I can and can't do in > Struts. > > I've been programming with it for 5 years. I know its power and I also > > know I've been involved with some amazingly convoluted hacks to make it > do > > what we needed. A framework that handles more of the request/response > > plumbing for me is welcome. A framework where *maybe* I can use tools > that > > are WYSIWYG if I want is appealling after 5 years of hand-coding XML > > descriptor files that are gigantic. A framework that handles requests > and > > responses and doesn't push as far back into the business tier is > welcome > > to me. > > > > So I like the idea of JSF. Just like I like the idea of Tapestry and > even > > Ruby on Rails. I just wanted to know if you could write a JSF app today > > and be reasonably sure that you could do easy validation on the server, > be > > relatively efficient in it and not run into major snafus with > application > > server differences. > > > > Preston > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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~
