This sounds to me like a rather blatant mis-use of actions. In the first place, as Michael points out, action chaining has always been an anti-pattern in Struts. As such, I'd be against promoting / encouraging the use of chaining in the way you describe (or in any other way, for that matter ;).
More importantly, it demonstrates the mis-use, IMHO, of actions as the basic unit of server-side logic, instead of simply the end-point for a request. An action represents the processing surrounding a complete request, not a part of a request. If there is a need to break that request processing into smaller units - and there frequently is - then the action should be the orchestrator of those units. For example, a common case would be one unit to handle the incoming request and a second to handle preparing to display the next page. Those two units would be two separate classes, not two actions chained together. -- Martin Cooper On 9/6/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
For a lack of a better subject line. Let me explain. I have some actions which are not supposed to be accessed by users. They are mostly for internal uses within the program. Specifically, I like to include many actions on a page and build a poor-man's portlet. So what I have, architecturally speaking, is one action whose view triggers a whole bunch of other actions. My thoughts lead me to this: while it is very low probability that these included action paths can be guessed at, I nevertheless do not enjoy it being above zero. I propose adding a new attribute which dictates when an action may be invoked. I do not have a favorite choice among my ideas, but here they are: 1) A public attribute; defaults to true. 2) A private attribute; defaults to false. 3) A dispatcher attribute; defaults to all; allows request|include|forward|error (like the filter dispatcher attribute of web.xml) For my needs, I want to be able to say which action mappings may not be directly accessed; they must be forwarded to or included by. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
