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 <[EMAIL PROTECTED]> wrote: > On 12/13/05, Alexandre Poitras <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
