I should have kept my mouth shut ;-) Paul's suggestion is *not* about chaining (while it *may* indirectly promote it).
As I understand it, Paul builds a page out of smaller blocks, each block is rendered by an action. I do the same thing and I do not oppose Paul in this regard. You are saying that "a common case would be one unit to handle the incoming request and a second to handle preparing to display the next page." This suggestion not about sequence of pages, it is about composition of one page out of several blocks, think Tiles or portlets. Using actions is a totally legitimate way to build composite page. Does not Tiles do the same? (I don't use Tiles so I don't know for sure.) Unlike Paul, I use included blocks (may I say "components") not only to render a composite page, but also as request targets. This way I can submit a request directly to a component without notifying the composite page itself. As such, I need the addresses of components to be exposed to the browser, therefore I do not need private actions. But I understand that others can use actions for page composition only and they do not want to expose these actions, in this case Paul's suggestion makes sense. On the other hand, these locations are not exposed to the browser anyway since the page is composed entirely on the server. The only reason for this enhancement is that "included action paths can be guessed at". Well, I don't know. So what if someone guessed them? Should not these actions be smart enough to not process input at all? They can use ActionForms with getters only. On 9/6/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
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]
