I would tend to agree with Martin. My feeling is that POJO Actions might encourage people to couch their business logic as POJO actions :)
It's unlikely that such a class could be a true POJO. It would have to be bound to Struts in some way. Otherwise, the Action would not produce a result that we could use in Struts. The role of an Action is to act as an adaptor *between* Struts and the business logic. As such, it needs *AND SHOULD HAVE* a foot in both worlds. IMHO, Actions are fine the way they are. The one and only problem is that people keep trying to use Actions (and Struts) as a component of a business logic framework, rather than as an *adjunct* to a business logic framework. My concern would be that POJO Actions sound like a slippery slope that will encourage more people to write applications with Struts, rather than *into* Struts. The reason we frown on chaining Actions is that it implies the business layer is "worthless and weak", so they need Struts to call their own business logic. IMHO, POJO Actions may cause similar problems, except that it will be even less obvious that people have married their business application to Struts. Actions should be a thin adaptor between Struts and the business-end of an application. The business-end can be written as Commands or with POJOs. But, we are not do anyone any favors if we encourage people to write Actions with "POJO" Actions. As Manfred mention, a good compromise might be make Action an interface sometime. People would then at least have to import the interface to mark what classes they are using as their Struts adapter. Though for 3.0.0, my recommendation would be to focus on shipping what we've got before stepping out onto any other limbs. But, maybe that's just me :) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
