Having a SuccessAction makes it much easier to do skeleton/storyboarded sites and fill in the details later. Switching from a SuccessAction to a real action when the time is right requires only changing the class name, not the structure of the action mapping XML too. In my Advanced Struts talks, I recommend a SuccessAction over ForwardAction as how I do it. Of course everyone's mileage may vary.
Parallel to all of this, I've been cleaning up some docs and preparing for another small release of the JGSI tools for Struts (http://demo.jgsullivan.com/struts/). The only new class, actually, is an action that also fits into this skeleton/storyboarding phase, so I thought I'd mention it to folks.
The class is called "SmartForwardingAction," and the idea is that you don't even have to bother entering action mappings into struts-config for this common case where you want to hide an essentially static page behind an action (along the Struts Catalog strategy "Use a forwarding Action for static pages."
If you register "SmartForwardingAction" as your "unknown" (default) action, it will take what would have been the action path, append ".jsp", and forward to that JSP. So if someone requests "/HelloWorld.do", the action looks for "/HelloWorld.jsp". If getRequestDispatcher() for that path returns null, an exception is thrown; otherwise, the execute method returns a ForwardingAction pointing to that path.
Actually, I'd been meaning to raise a question related to this to the developers -- to achieve this, I copied the "processPath" method out of the default RequestProcessor class. I was wondering if we might agree on a request attribute under which that path could be passed (i.e. Globals.ACTION_PATH_KEY) so that this action or any other action mapped under "unknown='true'" would have access to it. It's nothing huge, but it seems pretty safe.
See http://demo.jgsullivan.com/struts/SmartForwardingAction.html for a little more writeup. The class is in the 0.2-dev jar which can be downloaded from the above site in binary or source form. I'm working with Ted H. to get at least some of the JGSI struts tools into the Source Forge project -- I mostly just wanted to finish this documentation before putting it over there.
The other change for this small release is the addition of a default set of digester rules for creating a list of LabelValueBeans so that you can configure select menus for your application in XML files -- see http://demo.jgsullivan.com/struts/DigestingPlugIn_Example.html
Cheers,
Joe--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
