On 2/15/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Wed, February 15, 2006 2:46 pm, [EMAIL PROTECTED] said: > > Is it, however, possible that you could design you application to where > > all the mapped actions were "setup actions"? I guess not.
Yes you can. In this case you need to somehow distinguish the semantics of the request: do you want to render a page or do you want to submit input data. The choices are: * distinguish by request method (POST vs. GET). This is simple and it works, but all your input must be done via POST. This is how it works in .NET and it seems that the same approach is used in JSF. Hence the term "postback" not "getback" ;-) * distinguish by presence of a certain parameter in the request (event parameter). This means, that all your input must be send along with event name, therefore DispatchAction-type actions can be used very effectively here, directing request to a method that corresponds to event. This kind of action would process both render requests and input requests, for example: http://struts.sourceforge.net/strutsdialogs/dialogaction.html This concept seems a little complex for many people who got used to a pair of setup/input actions, so I am currently revising my library to employ MappingParameterDispatchAction (http://issues.apache.org/bugzilla/show_bug.cgi?id=38343) This one is worth checking out. I hope it makes into 1.3.1 > > Basically this > > is a question of whether we can introduce a hierachy into the actions? Is > > this a bad thing? Something that should already be handled? > > I guess the question to ask is what are the kinds of Actions... I don't > mean DispatchAction vs. Action vs. whateve else, but the *purpose* of the > Action. > > I can only see: > > * Setup Action, called when any page is first displayed > * Event Handler Action, called most usually in response to a form > submission. There is really two sub-types to this, one where the > resultant forward returns you to the same page, and one where it brings > you to another page. > > When you go to another page, the question is, do you forward directly to a > JSP (I'd bet most people do... I know I do that most often) or does it go > to another Action, which is the setup Action for the next page? An action should *never* forward to a page that does not belong to that action; this practice leads to a spaghetti code both in Java and in config file. > Some > people may refer to that as "action chaining", but I don't think it is. > If you always forward to another Action, instead of directly to JSPs, what > your rally doing is creating almost a prerender phase to the next page. I would say slightly different: what you really doing is transferring control to another web resource and you *do not care* which page will be shown. To select and to setup a proper page is the task of the resource you are forwarding to. > You also are giving yourself the opportunity to have more information, not > to mention control, over what goes on. Exactly, and to break your spaghetti-mappings into separate self-contained chunks. > In that way, I suppose you *could* create an app that was nothing but > setup actions... that would imply though that there are no events outside > page transitions... What do you mean? As I see it, every page (or a set of pages) belong to a particular pair of setup action / input action (or to a single dialog action). Setup action (I call it "render action") renders a page. When you click anywhere on this page or sumbit a form, event goes to an input action that belongs to this web resource. Event does not go outside! Only an action can transfer control to another action. > Action A executes to set up page A... > Page A is shown... > For submitted to Action A1, forward to Action B... > Action B executes to set up Page B... > Page B is shown... > ...and so on... If A and A1 belong to the same resource, then I agree with that. I would use redirect instead of forward simply to prevent double submit issues. What if you refresh page B? Redirection between resources does not imply that actionforms must be session-scoped ;-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
