Webstart has been around for awhile and it has its place but it's not going to make web applications go away any time soon. If JNDC and SandraSF do for Swing what Struts did for web applications, that will be good for Swing app developers but it has little to do with writing web applications. If you want a "rich client", Swing via Webstart is one way to do that.
Struts solved problems with Servlet/JSP specifications, but it built on their foundation. Now that the JSF standard has come along which has learned from the myriad of web application frameworks in existence, I think it would be in line with the Struts legacy to build around that standard and add value. I think the cycle of standard -> open source innovation -> standard -> open source innovation -> etc is a good one. We, in java land, are sort of at the point in the cycle where open source has several innovations that aren't yet standardized, but that doesn't mean that standards don't have value for all the usual reasons: Developer skill investment portability, application portability across vendor and time, IDE vendors return on investment for support standards, employers being able to draw on pool of skilled developers, etc. I haven't had a chance to use JSF for a client but I look forward to making the investment in learning it and I hope that the Struts community embraces it for 2.0. Based on the IBM JSF based framework and Springs ability to plug-in their managed bean factory, it seems like JSF is a very extensible framework that you can build web applications around, including next generation web applications, once the right JSF components are available. > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic > Sent: Wednesday, December 29, 2004 2:09 PM > To: dev@struts.apache.org > Subject: Re: RoadMap [was Re: ViewUtils ... ] > > Craig McClanahan wrote: > > > I believe that Struts will become > >gradually less relevant for new application development unless it > >adopts JSF strongly; > > > > :-). I don't think so. > > > and it would be a shame to have to *compete* with > >Struts instead of *being* Struts. > > > > > > > > Why not have JSF compete with HTML tag libs? Like Velcotiy does, etc. No > need to have a view Religion locked in MVC implementation - the C part. > If so, then lets all agree on one true DAO 1st, that is more mature > EJB? iBatis? Which JDO? Hibreante? Spring JDBC? Roll your own JDBC? > ... which is the official one? > Best thing about Java is choice. I think Caraig said way back "over my > dead body will there be a lock on a one DAO", or words to that effect. > > I will agree that "the view has been done in '04". If anyone has doubt > as to what view will win out in '05, take a look at my sample at > http://www.boardVU.com (in IE only for now - click on IE link. Also > SandraSF.com has javadocs. It's a chain based dispatcher that I will > port to Struts chain after chain becomes a bit more stable.). I see the > light, it's a diferent light. By next X-mass, JDNC will be a very > polular view tech in production, ahead of JSF and Tapestry. > If I was to limit myself to DHTML tech only... then clearly PHP is best, > look at all the PHP apps. Java is most competetive w/ JDNC. That is my > religion, the one true one, so all pray to my god! ;-) > > No mater how much skill and effort is put in JSF, it will not get > production market share, it will only move people to .NET ASP, thats > all. I do not think people should be disallowed to do JSF as view in > Struts, choice is good. If JSF makes improves... GREAT!!!!!!! > > I hope Struts contines to be View agnostic and that it even have some > SoA dispatch support in version 2 and 3. > > .V > > >Craig > > > > > > > -- > RiA-SoA w/JDNC <http://www.SandraSF.com> forums > - help develop a community > My blog <http://www.sandrasf.com/adminBlog> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
