We're in the middle of migrating our application from Struts to JSF. We have a ton of dialogs so we're starting with that. (We're using Shale for the dialogs btw, which I highly recommend.) My advice is to try and take a sizeable piece of your app and migrate that portion only. See what you like and don't like and get a better understanding of what will be required to migrate.
sean On 8/10/05, Zhai, Warren [IT] <[EMAIL PROTECTED]> wrote: > I only started looking at JSF a couple weeks ago, and I am convinced it's a > better presentation-tier web framework than STRUTS. Nonetheless, my current > project is STRUTS-based, and it's much easier if I can plug bits and pieces > of JSF into the application we are working on. > > Backward compatibility has always been important in IT. The more dominant and > successful the technical predecessor is, the more important it is to maintain > backward compatibility to ease developer transition. I feel that JSF is > overall a better framework, but the fact is that Sun, and other JSF vendors > have offered little to help developers to transition from STRUTS. > > Warren > > -----Original Message----- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 10, 2005 10:35 AM > To: MyFaces Discussion; [EMAIL PROTECTED] > Subject: Re: JSF vs. Struts > > > I think a big problem for JSF is that there are some crucial things > missing that most web developers take for granted. Most of that is > being addressed in JSF 1.2 but that is a long ways off. > > Two big ones jump to mind. The clientId problem was big for me. > That's why I added forceId. Nobody wants a framework changing their > element ids when trying to write complicated javascript. Also, the > verbatim thing is really awful. Once that's fixed you will get lots > more people jumping onboard. I understand its a complicated problem, > but the JCP folks also need to understand that will be a major turn > off to many web developers. > > I like to work with the cutting edge stuff and there is plenty of > benefit to using JSF now. But if you are less adventurous, you may > want to wait until JSF 1.2. There will also be a lot more components > to use by that point. > > sean > > > On 8/10/05, Werner Punz <[EMAIL PROTECTED]> wrote: > > Zhai, Warren [IT] wrote: > > > Just to add my 2 cents. JSF would have been much more successful if it > > > did the following: > > > > > Well the main problem JSF had, was in the beginning sort of that people > > looked instantly for their known Struts constructs (which were there but > > differently solved and better solved imho) and did not find them > > although the stuff looks very similar from the outside and then said it > > was not good enough. > > > > The other thing was, it was originally to little there component wise, > > giving to few additional value for an early jumpstart and not that much > > lighter on the config file level to give an incentive to switch instantly. > > Pushing out a JSF 1.0 with a huge component set which covers all the > > stuff needed for a good webapp would have been a clear winner, now it is > > slowly a winner but not a clear one. > > > > But given the fact that the tool vendors jump on it in masses and the > > tools really make the life easier. JSF has a serious impact, and most > > misunderstandings now have been solved either by components, extension > > frameworks or simply by better documentation, JSF has lots of momentum, > > at least that is my impression. > > > > > 1. Depict itself as a successor to STRUTS rather than a competitor. > > > 2. Provided easier side-by-side co-existence and allow finer grained > > > porting of a STRUTS application to the JSF framework. > > > > > Well coexistence frameworks exist, but given the fact that struts > > has so many things broken, it is better to take the existing good things > > of struts and try to solve the broken ones by a clean cut, instead of > > dragging the old stuff around for another decade. > > JSF in its current state is a very solid foundation and one of the > > better standards, it just needs additional value in the core, which > > MyFaces ADF faces and others deliver currently outside of the core. > > > > > > >
