On 5/24/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
but if you want to model best practices, then you have to ask "why would you be intent on calling Actions"? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that.
In SAF1 putting too much on Actions is considered a bad idea because those Actions are coupled to the web layer. Actions are used as an adapter between HTTP and the business logic, and we find, in practice, it's a bad idea to overload a SAF1 Action with additional responsibilities. In SAF2, Actions are not coupled to the web layer. Interceptors do the HTTP adapting. A SAF2 Action is the next best thing to a POJO. It's not correct to assume that every bad practice with a SAF1 Action is also going to be a bad practice with a SAF2 Action. One could even construct the business facade with XWork Actions and use those Actions in *any* programming environment. SAF2 Actions can be invoked and tested in isolation, just like any POJO facade. Right now, I'm constructing my facades with CoR Commands, but I could also see doing the same with SAF2 Actions. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
