Thanks for your comments ... I'll try to give you answers based on that
below.
On 1/11/06, Angel Navarro <[EMAIL PROTECTED]> wrote:
>
> 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.)
Ah, that makes sense.
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?
Makes perfect sense.
> 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?
Well, sort of. The basis for a lot of people's confusion is that JSF has a
front controller as well, and a *lot* better support for the model tier than
Struts 1.x does (see the managed beans facility). From a functionality
viewpoint, you will find that the functionality provided by Struts 1.x and
the functionality provided by JSF + Shale are essentially equivalent. There
are (relatively small) differences in how you program to the two -- and my
experience has been that JSF+Shale ends up with about the same numbers of
lines of JSP code, about the same number of lines of XML configuraiton, and
quite a bit less Java code. But your mileage may vary.
The struts-faces library is not deprecated, and won't be as long as there
are existing Struts 1.x applications that want to migrate to JSF. But,
that's not where I would recommend you start on a *new* project. Indeed, I
can state that rule very simply:
If your new project is going to require JSF, then use JSF+Shale.
Otherwise, evaluate both Struts 1.x and JSF+Shale based
to the application requirements and the abilities of your team.
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?
Pretty much. I've tried to give an indication about how stable *I* think
the Shale APIs are today, as well as who should even be looking at the APIs
in a particular page, on the Shale web site:
http://struts.apache.org/struts-shale/api-stability.html
The stuff marked "evolving" is pretty well baked, and you should expect no
disruptions. The stuff marked "developing" (except for the specific cases
that are marked experimental, is in the process of being baked, but there
are functionality additions we need to do that might have some impact on
existing users.
Have another alternative?
Of course! If you don't use JSF+Shale, use Struts 1.x :-).
What is the correct decision ? (in you opion)
My biases should be pretty obvious, but it really starts from one of your
decisions ... do you need the functionality provided by the libraries of JSF
components that are already available, or the ones that are in the progress
of being created? You won't go wrong with a JSF based solution. If not,
then the key thing to remember is that the Struts project gives you another
good choice, one that's been around for a long time and is well accepted.
Do you understand my problem, my decision?
>
> Thanks!
>
> Angel
Craig
