RE: Does Struts 2 solve the action chaining problem?
Craig and Mark, Thanks a lot for pointing out the Preparable interface. I think that solves a major problem with Struts 1. I'm yet to experiment heavily with WW/Struts 2, but I feel like the Interceptor concept is a very powerful approach, though a bit dangerous if not well controlled. Craig, We, actually, decided that we don't want to get into JSF yet. But if this prerender method is equivalent to the onPageLoad() method in ASP .NET, then it's a very important piece that is really missing from the JSF spec. Yujun, Your idea is brilliant and it never crossed my mind. If we stick with Struts 1, I think I will try that. Christopher, I really wonder if the Struts you're talking about is the one I've using for years now!! The Struts I know sucks big time when it comes to action chaining. I'm afraid I don't understand how defining two mappings, one with validation turned on and the other turned off, solves the first problem! As for the second problem, your solution still involves action chaining which should be avoided unless you've done something equivalent to what Yujun did. Thanks everyone for your help. -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 5:36 PM To: Struts Users Mailing List Subject: Re: Does Struts 2 solve the action chaining problem? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek, Tarek Nabil wrote: One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). I totally disagree. If you have an action that you want to use like this, you can always set up two different mappings -- one that /does/ validate and another that does /not/ validate. My experience has been that Struts is very good at action chaining... in fact, that's the major advantage of Struts in the first place: the ability to map URIs to actions and specify their relationships through forward mappings. Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. In this case, what you want is something like: LoadAction - EditAction - Display form Form submits to SaveAction, which has EditAction as input (not LoadAction). This is pretty standard stuff, and works beautifully. Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I really hope so, since Struts 1.x also does. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbYyx9CaO5/Lv0PARArpHAJ0U3fHybMWepSZxPjciDU3+6M2PwQCgoy8B FRlfdQsyONpgqGvrHBuZuFw= =EbD/ -END PGP SIGNATURE- DISCLAIMER This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof. If you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change.The sender shall not be liable for the improper or incomplete transmission of the information contained in this communication,nor for any delay in its receipt or damage to your system.The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk. ** - To unsubscribe, e-mail: [EMAIL
Re: Does Struts 2 solve the action chaining problem?
Action Chaining
First, we usually define action chaining as creating a move action
by having a copy action forward to a delete action. Simply going
from one action to another isn't a classic example of harmful
chaining. The key point is whether only one action resolves the
business use case.
Classic action chaining is considered harmful because it implies that
the Actions have become a business facade. Any Action should be able
to call facade.copy and facade.delete from a move Action. Better yet,
the facade should provide a move method, and implement it any way it
likes. We should not feel like we need to reuse multiple Action
classes to solve one business use case. Struts 1 Actions were intended
to be what Martin Fowler calls a transaction script, where move is
one transaction, not two.
The design of Struts 1 made action chaining difficult because s1
repopulates the request on every forward. When people start to use the
S1 actions as an API, they want to do things like change properites on
an ActionForm, and are surprised when the framework resets their
changes!
The Struts 2 group does discourgage classic Action chaining, because
it implies the business API is underdevelpoed. Albeit, we do provide a
action chaining result that copies the properties from one Action to
the next. The interceptor stack and result are processed for the
chained action, but the request doesn't pass back through the
container.
* http://struts.apache.org/2.x/docs/action-chaining.html
So you can set a flag on the copy action and have it picked up by the
delete action. This is *not* considered an ideal practice, since
coupling individual Action classes complicates the API, but it's there
when people choose to use it.
So, yes, Struts 2 has an elegant solution for action chaining, if you
choose to use it.
Control preparation
As mentioned, Struts 2 solves the control population issue via the
preparable interface. Another solution is to use the action tag to
execute an Action in place.
* http://cwiki.apache.org/confluence/display/WW/action
One way to use this tag is to put a control on a snippet JSP that is
rendered as a result of an Action that does nothing but create the
object that populates the control. The action tag sets
executeresult=true, then control markup will be included into the
page (like a tile), after the action executes.
In effect, exectuteResult actions can be used like a tag that can run
its own action before emitting the markup.
Input.jsp
%@ taglib prefix=s uri=/struts-tags %
s:form
s:action name=languages namespace=/ActionTag executeResult=true/
s:action name=colors namespace=/ActionTag executeResult=true/
ssubmit/
/s::form
Languages.jsp
%@ taglib prefix=s uri=/struts-tags %
s:select
tooltip=Choose Your Favorite Language
label=Favorite Language
list=favoriteLanguages
name=favoriteLanguage
listKey=key
listValue=description
emptyOption=true
headerKey=None
headerValue=None/
Languages.java (execute)
public String execute() {
favoriteLanguages.add(new Select.Language(EnglishKey,
English Language));
favoriteLanguages.add(new Select.Language(FrenchKey, French
Language));
favoriteLanguages.add(new Select.Language(SpanishKey,
Spanish Language));
return SUCCESS;
}
struts.xml (Input, Languages)
action name=Input
result type=plaintextInput.jsp/result
/action
action name=Languages class=app.Languages
resultLanguages.jsp/result
/action
The advantage being that the Languages action could be dropped in
whereever the Languages control is needed, and that the Action for
the form doesn't need to know how to populate the Languages control.
Now, the Action is going to be hit every time the page is rendered,
but so long as you are using a caching data access layer, like IBATIS
or Hibernate, it will end up being a memory-to-memory transfer, rather
than a database access.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
On 11/28/06, Tarek Nabil [EMAIL PROTECTED] wrote: Hi, One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. Struts 1.x works perfectly well in the above scenarios. You may want to check out the overview of Struts action usage in Struts wiki [1]. You can have one action handling both setup and input or you can have two separate classes. Also, you can have two different action forms or one action form. Struts populates an action form automatically, which seems like too much automation to me, but this cannot be changed now to ensure backwards compatibility. The specifics of handling form bean repopulation depend on chaining approach. If you use in-server forwarding, then you will have to place a token into the request object in the first action, and check this token in the target action (actually, you will probably be checking this flag in the form bean). If flag is there, this means that the action was chained by forwarding, and you have to prohibit updating a form bean. You can do this by putting an if into each and every setter of the form bean. Quite clunky. If you use a different action form for a chained action, you may want to define getters only, or to have setter methods that do not correlate with URL parameters. If you use redirection through browser, then just do not append any parameters to the target URL, this way a redirected request will be clean of parameters and Struts will not populate a form bean, because it has nothing to populate with. What is more, you can use one session-scoped form bean for both actions, it already has been set up, so you don't it to reinitialize it. [1] http://wiki.apache.org/struts/StrutsManualActionClasses - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
On 11/29/06, Yujun Liang [EMAIL PROTECTED] wrote: To solve the action chaining problem, I wrote a subclass of RequestProcessor. In the subclass, override some templates method. In the last method of process(), I set a flag in request, and I check for this flag in some methods and if the flag is there, it means it is the chained action and the processor will skip those template methods. This is an approach that I've been using for quite a while, before I switched to redirection. I think this feature can be included into future releases of Struts 1.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
If not this specific implementation, an otherwise clean way to handle view preprocessing after a validation failure. It can build on the action-forward-specific command chain, but a solution that's more tightly integrated with action objects should be considered as well. Hubert On 11/30/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 11/29/06, Yujun Liang [EMAIL PROTECTED] wrote: To solve the action chaining problem, I wrote a subclass of RequestProcessor. In the subclass, override some templates method. In the last method of process(), I set a flag in request, and I check for this flag in some methods and if the flag is there, it means it is the chained action and the processor will skip those template methods. This is an approach that I've been using for quite a while, before I switched to redirection. I think this feature can be included into future releases of Struts 1.x. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek, Tarek Nabil wrote: Christopher, I really wonder if the Struts you're talking about is the one I've using for years now!! The Struts I know sucks big time when it comes to action chaining. I'm afraid I don't understand how defining two mappings, one with validation turned on and the other turned off, solves the first problem! As for the second problem, your solution still involves action chaining which should be avoided unless you've done something equivalent to what Yujun did. I suppose I've never tried to modify the state of the request (or form bean) such that re-interpreting it across action invocations is relevant. I typically get information out of a form bean ASAP and then use that for some other operation (most often database interaction). Then I discard the form bean. If I have to re-read the form bean, it's in the same state in which I left it. I guess if you store a lot of state information in your form beans, and you mutate that information in your actions, you might end up fighting against Struts. As it is for me, forwarding from one action to another (that both use the same form bean) results in no problems except a slight performance hit for re-populating the bean and validating it when entering the second action. I never use beans that contain anything but Strings, so no conversion ever needs to take place. It looks like my mode of use has resulted in me never realizing what a PITA it might be when attempting to chain actions in this way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFb2by9CaO5/Lv0PARAtveAJ9AyWu4w0x7CUOuRvxXDjoKcVKbxwCfXCvc licIhQWz58NCiqrqaR8XwO8= =cSgU -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
To solve the action chaining problem, I wrote a subclass of RequestProcessor. In the subclass, override some templates method. In the last method of process(), I set a flag in request, and I check for this flag in some methods and if the flag is there, it means it is the chained action and the processor will skip those template methods. I think at least the following methods don't need to be executed in the chained actions, processHeader processLocale, processPopulate, processValidate, I solved the action chaining problem by extending the RequestProcessor, and it also improved the performance. For version 1.2.9 Regards On 11/29/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 11/28/06, Tarek Nabil [EMAIL PROTECTED] wrote: Hi, One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I remember coming across something about using Interceptors for that, but that would mean creating an Interceptor for almost every action of that type. I also noticed that there are some warnings in the documentation against using action chaining in Struts 2 as well. Interceptors are an O-O oriented approach to this kind of issue, but there are ligther weight alternatives. For the particular need of a setup action, consider the use of the Preparable interface in Struts 2. It's pretty similar to what the Tiles Controller interface supported in Struts 1.x ... a chance for your business logic to set up the stuff that is needed for rendering a particular view. If you're looking at JSF as a view technology, you'll likely be interested in what Shale http://shale.apache.org/; has to offer, particularly in the View Controller feature. Not only does the View Controller functionality support the setup scenario (via the prerender() callback method on the ViewController interface), it also supports cleaning up *after* the view has been rendered, via the destroy() callback. Craig -- Yujun Liang [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
On 11/29/06 12:44 AM, Tarek Nabil [EMAIL PROTECTED] wrote: One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. Yes, that can be an issue in Struts 1, as far as I know, but then again I never did serious Struts 1 development. As for S2 it's not an issue. With a reasonably configured interceptor stack and the use of the Preparable interface the issue doesn't exist. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). I haven't found a need for chaining yet in my S2 development. Using the prepare() method has sufficed for me. The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). Agreed, it would be nice if it just happened. You can do this in S2. Basically I have my interceptor stack configured to apply parameters to my action, run prepare, apply parameters again, then validate, then execute. All very neat. Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. Again I think the well configured interceptor stack has you covered. If you apply parameters after your prepare the users input will over write the values you've retrieved from the database, thereby preserving their input. Alternatively you could prepare the model once for the duration of the users interaction with a process by storing the data in the user's session, or in a conversation scope (cf. JIRA WW-1514 for an idea on how to do this, note this interceptor/interface is not done yet, nor is it official). Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I remember coming across something about using Interceptors for that, but that would mean creating an Interceptor for almost every action of that type. I also noticed that there are some warnings in the documentation against using action chaining in Struts 2 as well. Can't speak to the chaining issues. But as I've written I think you can solve the whole issue using the Prepareable interface and a well configured interceptor stack. Also, remember that you don't need to use the same stack for every action. You can apply interceptor stacks at the action and package level. That makes it pretty easy to manage. Take care, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek, Tarek Nabil wrote: One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). I totally disagree. If you have an action that you want to use like this, you can always set up two different mappings -- one that /does/ validate and another that does /not/ validate. My experience has been that Struts is very good at action chaining... in fact, that's the major advantage of Struts in the first place: the ability to map URIs to actions and specify their relationships through forward mappings. Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. In this case, what you want is something like: LoadAction - EditAction - Display form Form submits to SaveAction, which has EditAction as input (not LoadAction). This is pretty standard stuff, and works beautifully. Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I really hope so, since Struts 1.x also does. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbYyx9CaO5/Lv0PARArpHAJ0U3fHybMWepSZxPjciDU3+6M2PwQCgoy8B FRlfdQsyONpgqGvrHBuZuFw= =EbD/ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Does Struts 2 solve the action chaining problem?
Hi, One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I remember coming across something about using Interceptors for that, but that would mean creating an Interceptor for almost every action of that type. I also noticed that there are some warnings in the documentation against using action chaining in Struts 2 as well. Thanks, Tarek Nabil DISCLAIMER This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof. If you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change.The sender shall not be liable for the improper or incomplete transmission of the information contained in this communication,nor for any delay in its receipt or damage to your system.The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts 2 solve the action chaining problem?
On 11/28/06, Tarek Nabil [EMAIL PROTECTED] wrote: Hi, One of the problems with Struts was that if you had a page that requires some setup and this page submits to an Action, then you would not be able to set validate to true on that action because if validation problems occur then Struts will take you directly to the input JSP without performing the setup and your JSP wouldn't work. A solution to that would be to specify the input of the action as the setup action, which means you're doing action chaining and Struts is not good at that (it will reset your form among other things). The solution of choice for us so far was to call validate() ourselves in the action and if a validation problem occurs then we call the setup method (eventually you start using your action methods as an API which still was not good). Another problematic scenario is the case when you're editing some database record for example. When you go to your setup action for the first time, you will populate drop down lists for example, and then load the existing values from the database to your JSP fields. If the user attempts to save and some problem occurs then in the setup action, you will need to again populate the drop down lists, but you will NOT want to overwrite the user's inputs with the existing data. This is very similar to the first problem, but you would also need to pass some flag to the setup method to tell it whether to copy the data from the database to your ActionForm. Does Struts 2 or even WW 2.2.4 solve that problem in an elegant way? I remember coming across something about using Interceptors for that, but that would mean creating an Interceptor for almost every action of that type. I also noticed that there are some warnings in the documentation against using action chaining in Struts 2 as well. Interceptors are an O-O oriented approach to this kind of issue, but there are ligther weight alternatives. For the particular need of a setup action, consider the use of the Preparable interface in Struts 2. It's pretty similar to what the Tiles Controller interface supported in Struts 1.x ... a chance for your business logic to set up the stuff that is needed for rendering a particular view. If you're looking at JSF as a view technology, you'll likely be interested in what Shale http://shale.apache.org/; has to offer, particularly in the View Controller feature. Not only does the View Controller functionality support the setup scenario (via the prerender() callback method on the ViewController interface), it also supports cleaning up *after* the view has been rendered, via the destroy() callback. Craig
