RE: Struts 2: Providing Tiles Controller-like Functionality
Asleson, Ryan wrote: I've thought about writing a PreResultListener snip/ I've tried ActionInvocation.getResult(), but it only returns null. Is there a way to get the current Result object before it is actually executed? Looking at the code for DefaultActionInvocation, it seems that createResult() only gets called in executeResult(). If the your add() or remove() methods return an instance of a Result (instead of a String) then I would guess that ActionInvocation.getResult() would return what you expect, though returning a instance of Result may not fit your needs. What's strange is the documentation for DefaultActionInvocation.getResult(), which says: If the DefaultActionInvocation's result has not been executed before, the Result instance will be created and populated with the result params. The code in DefaultActionInvocation.getResult() doesn't seem to do that functionality though (and the fact that ActionInvocation.getResult() returns null seems like proof). An extremely hacky workaround _may_ be to cast your ActionInvocation to DefaultActionInvocation and then call the public createResult() method (though createResult() will be called twice if you do that: once by you and once by executeResult()). With a little more digging, you may be able to prove that this is a bug in Struts 2. Having said all that, can I backtrack for a second and ask if the following would solve your problem: Could you implement Preparable and have an empty prepare() method, plus prepareAdd() and prepareRemove() methods, each with preparation logic specific to add() and remove(), respectively? Brad Cupit Louisiana State University - UIS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts 2: Providing Tiles Controller-like Functionality
Hello, We're moving from a Struts 1.x with Tiles development model to Struts 2 and Sitemesh. One thing we miss with from Tiles is the ability to back a JSP with a Controller. The Controller guaranteed that whenever a JSP was rendered, certain behavior was executed to prepare data for the JSP. For example, the loading of data for drop-down select boxes was often placed in the Controller. Now that we're not using Tiles we can no longer use Controllers, so I'm wondering if Struts 2 has any sort of equivalent functionality. I'm familiar with the Struts 2 Preparable interface, but I don't like this because prepare() is always called -- even on form posts, which in my case, is at best an unnecessary database hit (or hits), and at worst can cause confusion with what was actually posted from the page vs. what was retrieved from prepare(). If it helps any, we have a 1:1 mapping between an Action and a JSP, including a naming convention: MyFavoriteAction maps to myFavorite.jsp. Any thoughts or comments? Thank you!! -Ryan This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you.
Re: Struts 2: Providing Tiles Controller-like Functionality
2008/6/23 Asleson, Ryan [EMAIL PROTECTED]: One thing we miss with from Tiles is the ability to back a JSP with a Controller. The Controller guaranteed that whenever a JSP was rendered, certain behavior was executed to prepare data for the JSP. For example, the loading of data for drop-down select boxes was often placed in the Controller. Now that we're not using Tiles we can no longer use Controllers Well, Tiles 1 controllers were renamed to view preparers in Tiles 2. See: http://tiles.apache.org/tutorial/advanced/preparer.html Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2: Providing Tiles Controller-like Functionality
Asleson, Ryan wrote: I'm familiar with the Struts 2 Preparable interface, but I don't like this because prepare() is always called -- even on form posts Do you have one Action with two public methods that are called by Struts 2? For example view() and submit() methods? If that's the case, I can understand why you wouldn't want prepare() called when submit() is called. To solve that, just rename your prepare method to prepareView(), and it will only run when view() is called. If you are not using multiple public methods in one Action, and each Action just implements the execute() method, I'd assume you have separate Actions for viewing and submitting, let's call them ViewAction and SubmitAction. In this situation, make your ViewAction implement Preparable, but don't have SubmitAction implement it. Am I way off base here? I personally like Preparable since the method gets called even when there is a validation error. So you have a place to put code that you want run both on initial display and on after a POST with validation errors. Brad Cupit Louisiana State University - UIS -Original Message- From: Asleson, Ryan [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 8:36 AM To: Struts Users Mailing List Subject: Struts 2: Providing Tiles Controller-like Functionality Hello, We're moving from a Struts 1.x with Tiles development model to Struts 2 and Sitemesh. One thing we miss with from Tiles is the ability to back a JSP with a Controller. The Controller guaranteed that whenever a JSP was rendered, certain behavior was executed to prepare data for the JSP. For example, the loading of data for drop-down select boxes was often placed in the Controller. Now that we're not using Tiles we can no longer use Controllers, so I'm wondering if Struts 2 has any sort of equivalent functionality. I'm familiar with the Struts 2 Preparable interface, but I don't like this because prepare() is always called -- even on form posts, which in my case, is at best an unnecessary database hit (or hits), and at worst can cause confusion with what was actually posted from the page vs. what was retrieved from prepare(). If it helps any, we have a 1:1 mapping between an Action and a JSP, including a naming convention: MyFavoriteAction maps to myFavorite.jsp. Any thoughts or comments? Thank you!! -Ryan This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2: Providing Tiles Controller-like Functionality
Thank you for your thoughts! Our model is to use one Action per JSP. So, for example, if a JSP has Add and Remove buttons, the Action has corresponding add() and remove() methods. We use this model because it cuts down on the proliferation of Action classes. Yes, Preparable is nice because it gets called even when validation errors occur, which is functionality we need. I've thought about writing a PreResultListener that checks the Result for the desired destination. If the destination (say, myFavorite.jsp) matches the Action (MyFavoriteAction.class) then run the prepare method. However, I can't find a way to get the current Result. I've tried ActionInvocation.getResult(), but it only returns null. Is there a way to get the current Result object before it is actually executed? This would help greatly. Any other thoughts are greatly appreciated. -Ryan -Original Message- From: Brad A Cupit [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 10:19 AM To: Struts Users Mailing List Subject: RE: Struts 2: Providing Tiles Controller-like Functionality Asleson, Ryan wrote: I'm familiar with the Struts 2 Preparable interface, but I don't like this because prepare() is always called -- even on form posts Do you have one Action with two public methods that are called by Struts 2? For example view() and submit() methods? If that's the case, I can understand why you wouldn't want prepare() called when submit() is called. To solve that, just rename your prepare method to prepareView(), and it will only run when view() is called. If you are not using multiple public methods in one Action, and each Action just implements the execute() method, I'd assume you have separate Actions for viewing and submitting, let's call them ViewAction and SubmitAction. In this situation, make your ViewAction implement Preparable, but don't have SubmitAction implement it. Am I way off base here? I personally like Preparable since the method gets called even when there is a validation error. So you have a place to put code that you want run both on initial display and on after a POST with validation errors. Brad Cupit Louisiana State University - UIS -Original Message- From: Asleson, Ryan [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 8:36 AM To: Struts Users Mailing List Subject: Struts 2: Providing Tiles Controller-like Functionality Hello, We're moving from a Struts 1.x with Tiles development model to Struts 2 and Sitemesh. One thing we miss with from Tiles is the ability to back a JSP with a Controller. The Controller guaranteed that whenever a JSP was rendered, certain behavior was executed to prepare data for the JSP. For example, the loading of data for drop-down select boxes was often placed in the Controller. Now that we're not using Tiles we can no longer use Controllers, so I'm wondering if Struts 2 has any sort of equivalent functionality. I'm familiar with the Struts 2 Preparable interface, but I don't like this because prepare() is always called -- even on form posts, which in my case, is at best an unnecessary database hit (or hits), and at worst can cause confusion with what was actually posted from the page vs. what was retrieved from prepare(). If it helps any, we have a 1:1 mapping between an Action and a JSP, including a naming convention: MyFavoriteAction maps to myFavorite.jsp. Any thoughts or comments? Thank you!! -Ryan This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail message is being sent solely for use by the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by phone or reply by e-mail, delete the original message and destroy all copies. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]