These are, of course, huge questions. And, I definitely agree with Ted on the POJO business. We need to remember, I think, that Actions are part of the framework, not part of applications. Unfortunately, too often the team builds functionality that should be part of applications and insinuates it into the framework: UploadAction and the way multipart requests are processed and LookupDispatchAction are examples. There really should be an application directory in Struts where these things should go and a mindset that they belong there architecture-wise as well.
Presently all the hub-bub about Commands/Chains is blurring the difference between the composable request processor and application logic. Making the framework extensible is one thing. Making the framework a sieve is another thing. Anyway, I really like what Ted has to say here. And, I hope Martin is saying that too. Unfortunately, I think, people tend to chain Actions not because they bring business logic into the actions but because they make Actions setup and teardown classes for pages rather than essentially classes that manage the lifecycle of the processing of a request. I like to think of an Action as a ProcessingManager for a particular request in a way not unlike the way the framework is a process manager for generic requests. Blah, blah, blah! I hope this is helpful. A compromise would be to keep Actions as they are except to make them interfaces, rather than make them interfaces and change signatures. Jack On Wed, 16 Mar 2005 07:19:10 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
