Is JSF ready?

[Preston Crawford <me...@prestoncrawford.com>]

I'm starting to begin looking at JSF in part because of what I've read
here on the Struts mailing list. i.e. Struts is embracing JSF, many
developers see it as inevitable. I have some experience with Tapestry and
Ruby on Rails so I'm excited about component frameworks. However, what I
don't know, having just started learning JSF is how ready it is. I can't
take wars developed in Java Studio Creator and deploy them to WebSphere
(we use WebSpere where I work) and I'm not sure how it stacks up to Struts
in terms of input validation, ease of integration with a business tier and
Hibernate and other common J2EE issues. Can anyone with experience give me
an idea if now is the time to jump in the water?

The reason I ask here is because of the nature of Struts creating new
projects to extend and enhance the JSF API. I don't know (with that in
mind) if that's a sign of JSF not being fully baked, or not being up to
par with what most Struts users are used to.

This is one of those situations where I want to pick the right horse. My
experience has been that usually the open source solution is the better
solution. See Ant, Struts, Spring, Hibernate, Tomcat as examples. So
because of licensing and who created the reference implementation I'm
naturally a little skeptical of JSF. Excited, but skeptical. Hopefully
someone can fill me in or at least explain what holes Shale is meant to
fill.

Preston


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Re: Is JSF ready?

[Alexandre Poitras <al...@gmail.com>]

I agree with you about the lack of components for the moment but
things are getting better.
Some commercials companies are giving their JSF implementation to Open
Source Community.

Oracle is already doing that with their ADF components wich are going
to become a sub project of Apache MyFaces, Cherokee.

Take a look at this link :
http://www.orablogs.com/jjacobi/archives/001540.html

Check out the Apache MyFaces Cherokee page
On 12/13/05, abdurrahman sahin <ab...@argela.com.tr> wrote:
> hi all;
>
> I'm currentyl using JSF for a project (I decided to use it because it has
> component model like asp.net does), I used ASP.NET before for some projects.
> In my opinion JSF so far away from what asp.net offers. I can't see any
> designer API provided (except that Sun Studio Creator).  also its component
> model is too weak. u have type even basic html inputs if u r developing a
> custom component. (look at asp.net's dozen of web controls;
> System.Web.UI.WebControls, System.Web.UI.HtmlControls)
>
> these are my opinions about JSF
> Best Regards
>
>
>
> -----Original Message-----
> From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> Sent: Tuesday, December 13, 2005 6:13 PM
> To: Struts Users Mailing List
> Cc: Struts Users Mailing List
> Subject: Re: [OT] Re: Is JSF ready?
>
>
> On Tue, December 13, 2005 10:25 am, Dave Newton said:
> > Just out of curiosity and for the sake of completeness, what didn't you
> > like/etc. about it? I'm also trying to decide whether or not to bother,
> > as I'm tending towards much lighter-weight/more agile webapp
> > methodologies these days.
>
> Well, to be very honest, I can't emumerate a lot of very specific things I
> liked or didn't like.  My current state of mind is more of a gut feeling
> kind of thing (which is a big part of the reason I continue to give it a
> chance and keep an open mind- my gut could be wrong!).
>
> That being said, there *are* a few at least somewhat specific things...
>
> * Contrary to what many people say, I don't find it to be any simpler than
> Struts or other frameworks I've looked at.  I have to factor in the fact
> that I'm not a JSF expert with this next statement, but I actually find it
> to be somewhat *more* complex.  I suspect there needs to be a
> differentiation between conceptual complexity and hands-on complexity
> though.  As far as hands-on goes, what code/config you actually need to
> write, I haven't seen anything that makes me think its any more complex,
> at least not to any substantial degree.  But conceptually, and probably
> because you need to trust the framework a little more to do more for you,
> I think JSF is a bit harder to get your brain around.  There is a bit more
> "mystery", so to speak, in what JSF is doing under the covers, and if you
> are a person, like me, who has a tough time having all those details
> hidden from you, it can paradoxically be harder to understand what is
> actually simpler.
>
> * While this isn't a failing of JSF, it has to be factored in: there is a
> lack of *good* examples and documentation in my opinion.  Oh, there is
> *plenty* of examples and documentation in general, but it seems to all be
> way too simplistic to be of any real help.  Or it's a kitchen sink thing
> and you can't parse out the necessary from the fluff.  Note that I'm
> talking about JSF in general... Shale has a lack of examples, although the
> documentation looks pretty good, but there are no tutorials that I'm aware
> of... none of this matters for Shale though because its still coming
> together and thus you cut it some slack.  JSF as a whole though is
> supposed to be mature, and part of maturity in my opinion is good
> documentation and examples.
>
> * When your working in Struts, there are canonical answers to most
> questions, best-practices ways of doing things.  The same is true of JSF.
> However, with Struts, if you want to "go off the reservation", so to
> speak, you can almost always do so without fighting the framework.  My
> experience is just the opposite with JSF.  If you like the "JSf Way", then
> you wouldn't have a problem with this, but if you like being in complete
> control, for me at least, its a problem.  While I'm sure you *can* go off
> the reservation with JSF as well, it seems like much more of a fight.
> Some people will like the rigidity and standardization JSF can bring, and
> logically I can see why, but I prefer the flexibility to do it *my* way,
> and that doesn't seem to be a strong suite of JSF.
>
> * Hype.  I generally recoil from anything that is hyped as much as JSF is,
> if for no other reason than I don't like being headrded around under any
> circumstances.  Now, all those doing the hyping may well believe every
> single word they are saying.  I certainly hope that is the case.  And in
> the end they may well wind up being right!  However, JSF is not something
> new.  It's been around for quite a while now, and it has yet to set the
> world on fire.  This doesn't make me right and them wrong by the way, but
> it *does* make you wonder if its all its cracked up to be.  I see JSF as
> being highly desirable for corporate interests, the tool vendors and those
> that will sell implementations and consulting services and all that, and
> that worries me.  I like the way Struts developed: put it out there with
> no motivation other than to help people, and let it develop as it will.
> If JSF had evolved the same way, I'd have one less worry/complaint about
> it, but as it stands I have to wonder what the real motivation is.
>
> Like I said, there isn't much technical points there, it's mostly
> psychological.  However, I don't see those types of objections mattering
> any less than technical ones.  One *should* however be willing to overcome
> those objections when sufficient reason becomes available, and that's why
> I continue to keep an open mind.
>
> > JSF seems in some ways like ASP.NET, but that's a very high-level
> > haven't-checked-it-out-much viewpoint. If it can be as rapid as ASP but
> > w/o dealing with any number of Microsoft issues, including technical and
> > philosophical, it could be neat on those bad days J2EE is a requirement.
>
> That is a fairly accurate comparison in terms of the overall approach.
> That's also one of the reasons tooling is so important for JSF to succeed:
> once you can build an application as easily as you can in Visual Studio,
> more people will be on board.  Arguably this isn't a good thing though...
> it tends to lower the caliber of developer at the same time.  But from the
> viewpoint of businesses, it's a great thing, and ultimately that's what
> tends to win the day... that's one of the reasons I won't place my bet
> down against JSF 100% just yet :)
>
> > Dave
>
> Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

RE: [OT] Re: Is JSF ready?

[abdurrahman sahin <ab...@argela.com.tr>]

hi all;

I'm currentyl using JSF for a project (I decided to use it because it has
component model like asp.net does), I used ASP.NET before for some projects.
In my opinion JSF so far away from what asp.net offers. I can't see any
designer API provided (except that Sun Studio Creator).  also its component
model is too weak. u have type even basic html inputs if u r developing a
custom component. (look at asp.net's dozen of web controls;
System.Web.UI.WebControls, System.Web.UI.HtmlControls)

these are my opinions about JSF
Best Regards



-----Original Message-----
From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
Sent: Tuesday, December 13, 2005 6:13 PM
To: Struts Users Mailing List
Cc: Struts Users Mailing List
Subject: Re: [OT] Re: Is JSF ready?


On Tue, December 13, 2005 10:25 am, Dave Newton said:
> Just out of curiosity and for the sake of completeness, what didn't you
> like/etc. about it? I'm also trying to decide whether or not to bother,
> as I'm tending towards much lighter-weight/more agile webapp
> methodologies these days.

Well, to be very honest, I can't emumerate a lot of very specific things I
liked or didn't like.  My current state of mind is more of a gut feeling
kind of thing (which is a big part of the reason I continue to give it a
chance and keep an open mind- my gut could be wrong!).

That being said, there *are* a few at least somewhat specific things...

* Contrary to what many people say, I don't find it to be any simpler than
Struts or other frameworks I've looked at.  I have to factor in the fact
that I'm not a JSF expert with this next statement, but I actually find it
to be somewhat *more* complex.  I suspect there needs to be a
differentiation between conceptual complexity and hands-on complexity
though.  As far as hands-on goes, what code/config you actually need to
write, I haven't seen anything that makes me think its any more complex,
at least not to any substantial degree.  But conceptually, and probably
because you need to trust the framework a little more to do more for you,
I think JSF is a bit harder to get your brain around.  There is a bit more
"mystery", so to speak, in what JSF is doing under the covers, and if you
are a person, like me, who has a tough time having all those details
hidden from you, it can paradoxically be harder to understand what is
actually simpler.

* While this isn't a failing of JSF, it has to be factored in: there is a
lack of *good* examples and documentation in my opinion.  Oh, there is
*plenty* of examples and documentation in general, but it seems to all be
way too simplistic to be of any real help.  Or it's a kitchen sink thing
and you can't parse out the necessary from the fluff.  Note that I'm
talking about JSF in general... Shale has a lack of examples, although the
documentation looks pretty good, but there are no tutorials that I'm aware
of... none of this matters for Shale though because its still coming
together and thus you cut it some slack.  JSF as a whole though is
supposed to be mature, and part of maturity in my opinion is good
documentation and examples.

* When your working in Struts, there are canonical answers to most
questions, best-practices ways of doing things.  The same is true of JSF.
However, with Struts, if you want to "go off the reservation", so to
speak, you can almost always do so without fighting the framework.  My
experience is just the opposite with JSF.  If you like the "JSf Way", then
you wouldn't have a problem with this, but if you like being in complete
control, for me at least, its a problem.  While I'm sure you *can* go off
the reservation with JSF as well, it seems like much more of a fight.
Some people will like the rigidity and standardization JSF can bring, and
logically I can see why, but I prefer the flexibility to do it *my* way,
and that doesn't seem to be a strong suite of JSF.

* Hype.  I generally recoil from anything that is hyped as much as JSF is,
if for no other reason than I don't like being headrded around under any
circumstances.  Now, all those doing the hyping may well believe every
single word they are saying.  I certainly hope that is the case.  And in
the end they may well wind up being right!  However, JSF is not something
new.  It's been around for quite a while now, and it has yet to set the
world on fire.  This doesn't make me right and them wrong by the way, but
it *does* make you wonder if its all its cracked up to be.  I see JSF as
being highly desirable for corporate interests, the tool vendors and those
that will sell implementations and consulting services and all that, and
that worries me.  I like the way Struts developed: put it out there with
no motivation other than to help people, and let it develop as it will.
If JSF had evolved the same way, I'd have one less worry/complaint about
it, but as it stands I have to wonder what the real motivation is.

Like I said, there isn't much technical points there, it's mostly
psychological.  However, I don't see those types of objections mattering
any less than technical ones.  One *should* however be willing to overcome
those objections when sufficient reason becomes available, and that's why
I continue to keep an open mind.

> JSF seems in some ways like ASP.NET, but that's a very high-level
> haven't-checked-it-out-much viewpoint. If it can be as rapid as ASP but
> w/o dealing with any number of Microsoft issues, including technical and
> philosophical, it could be neat on those bad days J2EE is a requirement.

That is a fairly accurate comparison in terms of the overall approach.
That's also one of the reasons tooling is so important for JSF to succeed:
once you can build an application as easily as you can in Visual Studio,
more people will be on board.  Arguably this isn't a good thing though...
it tends to lower the caliber of developer at the same time.  But from the
viewpoint of businesses, it's a great thing, and ultimately that's what
tends to win the day... that's one of the reasons I won't place my bet
down against JSF 100% just yet :)

> Dave

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Re: Is JSF ready?

["Frank W. Zammetti" <fz...@omnytex.com>]

On Tue, December 13, 2005 10:25 am, Dave Newton said:
> Just out of curiosity and for the sake of completeness, what didn't you
> like/etc. about it? I'm also trying to decide whether or not to bother,
> as I'm tending towards much lighter-weight/more agile webapp
> methodologies these days.

Well, to be very honest, I can't emumerate a lot of very specific things I
liked or didn't like.  My current state of mind is more of a gut feeling
kind of thing (which is a big part of the reason I continue to give it a
chance and keep an open mind- my gut could be wrong!).

That being said, there *are* a few at least somewhat specific things...

* Contrary to what many people say, I don't find it to be any simpler than
Struts or other frameworks I've looked at.  I have to factor in the fact
that I'm not a JSF expert with this next statement, but I actually find it
to be somewhat *more* complex.  I suspect there needs to be a
differentiation between conceptual complexity and hands-on complexity
though.  As far as hands-on goes, what code/config you actually need to
write, I haven't seen anything that makes me think its any more complex,
at least not to any substantial degree.  But conceptually, and probably
because you need to trust the framework a little more to do more for you,
I think JSF is a bit harder to get your brain around.  There is a bit more
"mystery", so to speak, in what JSF is doing under the covers, and if you
are a person, like me, who has a tough time having all those details
hidden from you, it can paradoxically be harder to understand what is
actually simpler.

* While this isn't a failing of JSF, it has to be factored in: there is a
lack of *good* examples and documentation in my opinion.  Oh, there is
*plenty* of examples and documentation in general, but it seems to all be
way too simplistic to be of any real help.  Or it's a kitchen sink thing
and you can't parse out the necessary from the fluff.  Note that I'm
talking about JSF in general... Shale has a lack of examples, although the
documentation looks pretty good, but there are no tutorials that I'm aware
of... none of this matters for Shale though because its still coming
together and thus you cut it some slack.  JSF as a whole though is
supposed to be mature, and part of maturity in my opinion is good
documentation and examples.

* When your working in Struts, there are canonical answers to most
questions, best-practices ways of doing things.  The same is true of JSF. 
However, with Struts, if you want to "go off the reservation", so to
speak, you can almost always do so without fighting the framework.  My
experience is just the opposite with JSF.  If you like the "JSf Way", then
you wouldn't have a problem with this, but if you like being in complete
control, for me at least, its a problem.  While I'm sure you *can* go off
the reservation with JSF as well, it seems like much more of a fight. 
Some people will like the rigidity and standardization JSF can bring, and
logically I can see why, but I prefer the flexibility to do it *my* way,
and that doesn't seem to be a strong suite of JSF.

* Hype.  I generally recoil from anything that is hyped as much as JSF is,
if for no other reason than I don't like being headrded around under any
circumstances.  Now, all those doing the hyping may well believe every
single word they are saying.  I certainly hope that is the case.  And in
the end they may well wind up being right!  However, JSF is not something
new.  It's been around for quite a while now, and it has yet to set the
world on fire.  This doesn't make me right and them wrong by the way, but
it *does* make you wonder if its all its cracked up to be.  I see JSF as
being highly desirable for corporate interests, the tool vendors and those
that will sell implementations and consulting services and all that, and
that worries me.  I like the way Struts developed: put it out there with
no motivation other than to help people, and let it develop as it will. 
If JSF had evolved the same way, I'd have one less worry/complaint about
it, but as it stands I have to wonder what the real motivation is.

Like I said, there isn't much technical points there, it's mostly
psychological.  However, I don't see those types of objections mattering
any less than technical ones.  One *should* however be willing to overcome
those objections when sufficient reason becomes available, and that's why
I continue to keep an open mind.

> JSF seems in some ways like ASP.NET, but that's a very high-level
> haven't-checked-it-out-much viewpoint. If it can be as rapid as ASP but
> w/o dealing with any number of Microsoft issues, including technical and
> philosophical, it could be neat on those bad days J2EE is a requirement.

That is a fairly accurate comparison in terms of the overall approach. 
That's also one of the reasons tooling is so important for JSF to succeed:
once you can build an application as easily as you can in Visual Studio,
more people will be on board.  Arguably this isn't a good thing though...
it tends to lower the caliber of developer at the same time.  But from the
viewpoint of businesses, it's a great thing, and ultimately that's what
tends to win the day... that's one of the reasons I won't place my bet
down against JSF 100% just yet :)

> Dave

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

[OT] Re: Is JSF ready?

[Dave Newton <ne...@pingsite.com>]

Frank W. Zammetti wrote:

>If you really want another opinion for your tally sheet, put me down as
>not a big fan.  My JSF experiences have not been encouraging [...]
>
Just out of curiosity and for the sake of completeness, what didn't you 
like/etc. about it? I'm also trying to decide whether or not to bother, 
as I'm tending towards much lighter-weight/more agile webapp 
methodologies these days.

JSF seems in some ways like ASP.NET, but that's a very high-level 
haven't-checked-it-out-much viewpoint. If it can be as rapid as ASP but 
w/o dealing with any number of Microsoft issues, including technical and 
philosophical, it could be neat on those bad days J2EE is a requirement.

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Is JSF ready?

["Frank W. Zammetti" <fz...@omnytex.com>]

On Tue, December 13, 2005 7:27 am, Alexandre Poitras said:
> One advice, there's a lot of FUD spread around JSF right now
> so try it by yourselft first before listening to other people.

This is perhaps the best bit of advice anyone could give.  For whatever
reason, JSF has engendered a great deal of strong feelings on both sides
of the like it/love it fence.  Do yourself a favor and don't even bother
with opinions at this point.  Just play with it and see what you think.

One seemingly universal truth is that if you are going to like it, chances
are it will take a little while.  I haven't talked to many people that
instantly loved it, but I have spoken to numerous people who didn't like
it at first and gradually they came to like it a great deal.  So give it a
fair shake before you decide.

If you really want another opinion for your tally sheet, put me down as
not a big fan.  My JSF experiences have not been encouraging, but notice I
said experienceS... I keep going back and giving it another shot, hoping
the epiphany that many people seem to have will hit me too.  It hasn't yet
though.  It seems that for everything I see that is good about it, I find
something that I think is bad, so on balance I remain unconvinced.

But, my opinion is no better than anyone else', so give it a try yourself,
and give it some time to grow on you, and see if it does.

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Is JSF ready?

[Alexandre Poitras <al...@gmail.com>]

I don't agree with some of your statements. I know it is possible to
implement most of JSF things using Struts but unfortunately you have
to do it yourself.

For exemple, to use DispatchAction for events like you suggested, you
need one different method for each event or use an extra argument to
determine the type of event. You may argue that it's not necessary
because you just tell the button to go straight to the action. But
suppose you need to support more than one type of event having the
same treatment but with slight differences, you will have to
distinguish the type of events. And if you want the event source, you
have to be sure the request contains the necessary values, then
extract them and finally interprets them yourself. All this plumbing
is supported out of the box with components framework by the
abstraction of user events. You don't have to care about this low
level stuff. From my experience, it is quite productive.

Another exemple, you want a dynamic session-scoped menu in Struts.
Unless you use Struts-Menu and learn another *framework*, you need to
create a new Action Form to keep all the parameters or you can deal
directly with the session object. Again you have to reinvent the wheel
or deal with low level stuff, wich in my main increase the risk of
errors. With JSF, you just reuse an available component Nothing new to
learn except the properties of the component.

I don't want to start a Struts vs JSF war but I find JSF or Tapestry
just more natural to use because they support higher abstractions. But
nowadays C is still used because some people don't like OOP, so you
can stay with Struts if you are more confortable with it. The point of
my first anwser was give it a try and see if it fit you.



On 12/13/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 12/13/05, Alexandre Poitras <al...@gmail.com> wrote:
> > First, it [JSF] is component oriented so it is easier to reuse
> > code between applications and easier to understand.
>
> Struts can be easily made component-oriented.
>
> > Plus, the
> > components are STATEFUL, they keep their state between request and
> > that is a big advantage of JSF. In Struts, only the forms input
> > controls were stateful and only if your form beans had session scope.
>
> Have JSF invented another method to keep application state? In Struts
> one can use action form both for input and output, which makes it a
> conversational input/output object, a view buffer, a managed bean if
> you will.
>
> > Also, JSF provides a fine-grained event model à la Swing compare to
> > the coarse-grained event model of Struts (receive request, do
> > something).
>
> DispatchAction et al?
>
> > Finally, the best part of JSF comes from method and value
> > binding wich allows you to use normal Java Beans for your controller
> > (think of it as a Dispatch Action merged with an Action Form).
>
> Combining DispatchAction with ActionForm would be a simple change for
> Struts, without breaking compatibility. For some reason that did not
> happen [yet?].
>
> <skipped>
>
> JSF has its benefits, but the features that you quoted are not unique
> for JSF. The same practices can be easily used with Struts.
>
> > Alexandre Poitras
> > Québec, Canada
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Is JSF ready?

[Michael Jouravlev <jm...@gmail.com>]

On 12/13/05, Alexandre Poitras <al...@gmail.com> wrote:
> First, it [JSF] is component oriented so it is easier to reuse
> code between applications and easier to understand.

Struts can be easily made component-oriented.

> Plus, the
> components are STATEFUL, they keep their state between request and
> that is a big advantage of JSF. In Struts, only the forms input
> controls were stateful and only if your form beans had session scope.

Have JSF invented another method to keep application state? In Struts
one can use action form both for input and output, which makes it a
conversational input/output object, a view buffer, a managed bean if
you will.

> Also, JSF provides a fine-grained event model à la Swing compare to
> the coarse-grained event model of Struts (receive request, do
> something).

DispatchAction et al?

> Finally, the best part of JSF comes from method and value
> binding wich allows you to use normal Java Beans for your controller
> (think of it as a Dispatch Action merged with an Action Form).

Combining DispatchAction with ActionForm would be a simple change for
Struts, without breaking compatibility. For some reason that did not
happen [yet?].

<skipped>

JSF has its benefits, but the features that you quoted are not unique
for JSF. The same practices can be easily used with Struts.

> Alexandre Poitras
> Québec, Canada

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Is JSF ready?

[Alexandre Poitras <al...@gmail.com>]

JSF is more powerful than Struts in many ways. In fact, the original
creator of Struts, Craig McClanahan, was the co-spec lead of JSF
expert group and he is one of the author of Shale (Struts sub-project
aimed at extending JSF). JSF provides all the Struts features, ie.
validation, conversion, navigation, messages, ... and all those
features are extendable. But JSF dissociates itself from Struts in a
lot of areas. First, it is component oriented so it is easier to reuse
code between applications and easier to understand. Plus, the
components are STATEFUL, they keep their state between request and
that is a big advantage of JSF. In Struts, only the forms input
controls were stateful and only if your form beans had session scope.
Also, JSF provides a fine-grained event model à la Swing compare to
the coarse-grained event model of Struts (receive request, do
something). Finally, the best part of JSF comes from method and value
binding wich allows you to use normal Java Beans for your controller
(think of it as a Dispatch Action merged with an Action Form). It so
easy to test compare to Struts action and action forms. I have been
developping for several years with Struts and I didn't like it (even
if it was making things better then using only jsp/servlets). There
were so many problems and it was hard to reuse anything from that
code. Trust me, if you liked Tapestry (wich is a reliable alternative
in my mind), you will probably love JSF. The rough spot of JSF in my
opinion is JSP integration wich is in my mind a big mistake but there
are some good alternatives out there (Shale Clay and facelet).

About Shale, Struts Shale is just a subproject of Struts. It has
nothing to do with it, it just shares the user community. Struts is
going to stay a classical Action oriented framework while Shale is a
framework built around JSF. Shale is kind of an experimental ground to
add things that weren't cover by JSF spec. It adds stuff you are used
to in Struts. For exemple, with Shale you can have application wide
functionnalities like with Struts RequestProcessor. Shale also add
page functionalities, ie kind of like when you have an action in
Struts wich is responsable to load data before displaying the view.
Shale also add the concept of dialog by bringing the Spring Webflow
implementation to the JSF world. I haven't tried it yet but seems
quite powerful. With Shale, you also have support for Apache commons
validators and so client-side validation. Finally, Shale-Clay plug-in
allows you to reuse some subview easily and provide you integration
with different choice of view technologies (XHTML, XML) to use instead
of JSP.

Well, that's the best I can say in such a short text but there a lot
more then that about JSF. You should start reading to make your own
opinion. One advice, there's a lot of FUD spread around JSF right now
so try it by yourselft first before listening to other people. But
there are  good alternatives to JSF. I have not tried all of them but
there all several other components frameworks like Tapestry, Echo and
Wicky.

On 12/13/05, Preston Crawford <me...@prestoncrawford.com> wrote:
> I'm starting to begin looking at JSF in part because of what I've read
> here on the Struts mailing list. i.e. Struts is embracing JSF, many
> developers see it as inevitable. I have some experience with Tapestry and
> Ruby on Rails so I'm excited about component frameworks. However, what I
> don't know, having just started learning JSF is how ready it is. I can't
> take wars developed in Java Studio Creator and deploy them to WebSphere
> (we use WebSpere where I work) and I'm not sure how it stacks up to Struts
> in terms of input validation, ease of integration with a business tier and
> Hibernate and other common J2EE issues. Can anyone with experience give me
> an idea if now is the time to jump in the water?
>
> The reason I ask here is because of the nature of Struts creating new
> projects to extend and enhance the JSF API. I don't know (with that in
> mind) if that's a sign of JSF not being fully baked, or not being up to
> par with what most Struts users are used to.
>
> This is one of those situations where I want to pick the right horse. My
> experience has been that usually the open source solution is the better
> solution. See Ant, Struts, Spring, Hibernate, Tomcat as examples. So
> because of licensing and who created the reference implementation I'm
> naturally a little skeptical of JSF. Excited, but skeptical. Hopefully
> someone can fill me in or at least explain what holes Shale is meant to
> fill.
>
> Preston
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--
Alexandre Poitras
Québec, Canada

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Taglib

[Gaet <ga...@free.fr>]

Does someone knows a good taglib to display a "popup frame", charts and so on...?

Thanks for sharing!

Re: Is JSF ready?

[Dakota Jack <da...@gmail.com>]

I don't think it is accurate to say that "Struts is embracing JSF".  More
accurate, probably, would be that Struts tolerates JSF because Craig's
career is presently tied to JSF.  That's okay with me and nobody in
particular cares whether I like or or not, but that is not an endorsement so
much as a sop.  JSF has been around forever, by the way.  Tapestry is
superior, in my opinion.

On 12/12/05, Preston Crawford <me...@prestoncrawford.com> wrote:
>
> I'm starting to begin looking at JSF in part because of what I've read
> here on the Struts mailing list. i.e. Struts is embracing JSF, many
> developers see it as inevitable. I have some experience with Tapestry and
> Ruby on Rails so I'm excited about component frameworks. However, what I
> don't know, having just started learning JSF is how ready it is. I can't
> take wars developed in Java Studio Creator and deploy them to WebSphere
> (we use WebSpere where I work) and I'm not sure how it stacks up to Struts
> in terms of input validation, ease of integration with a business tier and
> Hibernate and other common J2EE issues. Can anyone with experience give me
> an idea if now is the time to jump in the water?
>
> The reason I ask here is because of the nature of Struts creating new
> projects to extend and enhance the JSF API. I don't know (with that in
> mind) if that's  sign of JSF not being fully baked, or not being up to
> par with what most Struts users are used to.
>
> This is one of those situations where I want to pick the right horse. My
> experience has been that usually the open source solution is the better
> solution. See Ant, Struts, Spring, Hibernate, Tomcat as examples. So
> because of licensing and who created the reference implementation I'm
> naturally a little skeptical of JSF. Excited, but skeptical. Hopefully
> someone can fill me in or at least explain what holes Shale is meant to
> fill.
>
> Preston
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~