Hi Craig, thanks for you reply.
> For the purposes of this reply, I'm going to assume by your use of the term > "Struts" that you mean the existing Struts 1.1 or 1.2 (or the upcoming 1.3 ) > framework, correct? Yes, I know Struts 1.1 or 1.2 and in other project, I used Struts 1.1. > If you are absolutely required to use Struts 1.x and JSF together, then > struts-faces is your alternative. It's primary purpose is to enable > existing Struts based applications to be migrated -- but it can serve as the > basis for new development as well. No, I have not requirements, but It's my responsability make a new architecture for a Portal of an important financial bussiness. (Sorry, my only requeriment are to use J2EE.) I have fear to use a technology that in few months are deprecated. But also I have fear to use a new technology that actually it is not stable, you know? > That being said, the combination is not the path I would recommend for new > development, because you end up with a lot of redundant functionality (two > ways to do navigation, two ways to do validation, two ways to do conversion, > and so on) that will make maintaining the application more complicated than > it needs to be. If JSF is a requirement, I would recommend lobbying for > using either JSF by itself, or JSF with Shale -- the combination gives you > pretty much the same set of overall functionality that Struts 1x does > (including client side validation and support for Tiles), but without the > duplications. Is correct to think thant JSF is the technology to use in the view tier and Struts as the Controller and model?...the union is the technology of future? If this is correct, actually, have two alternatives for a new web application: - Develop the new application using Struts 1.x (perhaps 1.3 ?¿?, is a production version?), and use Struts-Faces or - Develop the new application using Shale (but Shale is ready for new develops?) Is this correct? Have another alternative? What is the correct decision ? (in you opion) Do you understand my problem, my decision? Thanks! Angel 2006/1/11, Craig McClanahan <[EMAIL PROTECTED]>: > > On 1/10/06, Angel Navarro <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I have to take a difficult decision. > > > > I have to develop a new web application and I think that I have to use > > JSF, > > but I also think that I have use Struts as Controller. > > > For the purposes of this reply, I'm going to assume by your use of the > term > "Struts" that you mean the existing Struts 1.1 or 1.2 (or the upcoming 1.3 > ) > framework, correct? > > The web application that I have to develop it's a medium, big application. > > > > The two alternatives are Shale or Struts-faces, correct?, > > > Not really. Shale is a completely separate framework that leverages the > fact that JSF already provides a controller servlet, plus support for > navigation and other simiklar things. It shares no code with the > Struts 1.xcontroller framework. > > but Shale I think > > that is not a final version, and perhaps it's a risk decision...... > > But Struts-Faces, perhaps in few months, will be deprecated?.....it's a > > good > > alternative?, I don't know! > > Have another alternative????, in this moment, I have a big problem!!! > > > > Thanks and sorry by my English ;) > > > If you are absolutely required to use Struts 1.x and JSF together, then > struts-faces is your alternative. It's primary purpose is to enable > existing Struts based applications to be migrated -- but it can serve as > the > basis for new development as well. > > That being said, the combination is not the path I would recommend for new > development, because you end up with a lot of redundant functionality (two > ways to do navigation, two ways to do validation, two ways to do > conversion, > and so on) that will make maintaining the application more complicated > than > it needs to be. If JSF is a requirement, I would recommend lobbying for > using either JSF by itself, or JSF with Shale -- the combination gives you > pretty much the same set of overall functionality that Struts 1x does > (including client side validation and support for Tiles), but without the > duplications. > > Angel > > > > Craig > >
