One way to look at the whole Struts vs. JSF issue is to think about it in terms of architecture and maintenance. There are a lot of JSF features that one could easily respond to by saying "Yes, well Struts has that too." This was my first reaction and the brand new stuff will obviously draw the most initial interest.
As Craig has pointed out in the last post there are lots of similarities. Even though there are some cases where JSF features are similar, I have found that they are often implemented in a superior fashion. No suprise here as the JSF group was able to draw on lessons learned from Struts (and other frameworks.) One new feature that I love is the value change event. This was something that I really needed in my struts apps. When writing a webapp that is more "app" than "web" you're not just filling out forms and updating shopping carts. Sometimes you'd really like to know when field x has changed. In Struts I had to basically had to stored cloned copies of my beans in the form because I wanted to know which fields had changed and what the previous and new values were. Now in JSF, you just have to use the value change event. No more implementing cloneable for every freakin bean (and member bean.) Nice elegant solution. The more stuff in JSF that I find like this, the closer I move towards implementing the next app w/faces (or Shale) instead of Struts. Anyways, that's just another way of looking at it. sean --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
