Can anyone elaborate on how to use the SwitchAction class. Specifically, how does one populate the two request paramters "prefix" and "page". Note that these are not request attributes.
Thanks, JOHN -----Original Message----- From: micael [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 11:15 AM To: Struts Users Mailing List Subject: Re: Sub Apps Damn, Eddie! Nice job! At 11:34 PM 9/16/2002 -0500, you wrote: >On a very high-level, yes :-) > >Back in the old days (Struts 1.0), you used to have one application. You >configured the action servlet in web.xml, and told it where to find your >one (and only) struts-config.xml file. This one file was where all of >your application config was kept. Unfortunately, there was contention >when multiple people needed to update the configuration file. > >... along comes 1.1 (beta) > >Now, you can have as many configuration files as you have modules. Each >module will (presumably) be handled by one team, so contention is less. >Each module can be independently developed - caring nothing about the >others, unless it has to. This is better for multi-developer settings. To >ease the transition, there is always one module -- the default >module. That module lives (speaking in URI-terms) at >http://mydomain.dom/appContext/. All other modules live at >http://mydomain.dom/appContext/module/. > >By default, all paths are treated as relative to the module context. Since >this happens to be the same as the applciation context for the default >application, struts 1.0 applications should be able to easily migrate to >1.1. You could then convert over to the new modules strategy "one piece >at a time". > >That a "birds-eye view" of sub-applications. Is that what you wanted? >Need more details? Oh, what the heck - here: > >It's really quite easy to implement. You just ... well, in your web.xml, >you do something like this: > > <!-- Default Sub-Application Config --> > <init-param> > <param-name>config</param-name> > <param-value>/WEB-INF/conf/struts-default.xml</param-value> > </init-param> > <!-- ModuleA Sub-Application Config --> > <init-param> > <param-name>config/modulea</param-name> > <param-value>/WEB-INF/conf/struts-moduleb.xml</param-value> > </init-param> > <!-- ModuleB Sub-Application Config --> > <init-param> > <param-name>config/moduleb</param-name> > <param-value>/WEB-INF/conf/struts-moduleb.xml</param-value> > </init-param> > >Each file is a struts-config file. What you're actually doing when you >specify the config elements, is saying "make this module live at ><app-context>/<module>". So, from the example above, we would reach >module a by using a URL like: > >http://localhost:8080/myApp/modulea/index.do > >We could reach moduleb by doing something like: > >http://localhost:8080/myApp/moduleb/index.do > >Both of my examples depend on one very important key: You should have an >action setup for each of them that maps to /index. Provided that you have >done that, you'll have good results. > >Let's look at one of the struts-config files: > ><struts-config> > <form-beans/> > <global-forwards> > <forward contextRelative="true" > name="toDefault" > path="/index.do" > redirect="true"/> > <forward contextRelative="true" > name="toModuleA" > path="/modulea/index.do" > redirect="true"/> > <forward contextRelative="true" > name="toModuleB" > path="/moduleb/index.do" > redirect="true"/> > </global-forwards> > <action-mappings> > <action path="/index" > parameter="/default/moduleindex.jsp" > type="org.apache.struts.actions.ForwardAction"> > </action> > </action-mappings> > <message-resources key="org.apache.struts.action.MESSAGE" > >parameter="com.mycompany.struts.module.DefaultResources"/> ></struts-config> > >The global-forwards gives me a way to get from this sub-application (this >is a cut-down excerpt from my struts-default.xml) to my other >sub-applications. Every one of my struts-<module>.xml files has these >very same global-forwards. I just copied and pasted them from one to the >other. I made them all context-relative (that means -- interpret this >path as though it is relative to the APPLICATION-context -- not the >module-context. Struts, by default, will interpret your paths as being >relative to the module-context). There are other ways to change >sub-applications too. org.apache.struts.actions.SwitchAction will do this >for you. Be sure you give it both required request parameters: prefix >(the module name preceeded by a '/' -- as in /modulea) and page (if you do >a type-o like I did, and get an exception saying to use prefix and path >just ignore it. It is incorrect. I already filed a bug and submitted a >patch). > >To make navigation among modules easy, all of them have an index action. >That is the primary entry-point from one module to another. I may or may >not have additional links into other sub-applications, depending on what >my requirements are. That's something you'll have to judge for yourself. > >You'll notice some convention I use. Each of my modules has it's own >directory under the application root. I keep things relating to a given >module in it's own directory. I also have a common directory which houses >things that get shared (like layouts etc). Unfortunately, I haven't >managed to make Tiles work correctly with sub-applications yet. I may be >doing something wrong. That's why you don't see the TilePlugin being >installed. I just use JSP pages for my definitions. I haven't tried the >Validator out with them yet -- haven't got along that far with my >prototype. I guess I should. > >I wasn't going to go into so much depth, but I'm nearly certain the >high-level description I started out with wasn't what you were looking for. > >Oh - one last note - you *must* go through the controller (ie through an >action) if you want your request to be associated with one of the >non-default sub-applications. My experiments have shown that I can view >JSP pages directly, and have resources pulled back, but those resources >are always the ones for the main (default) sub-application. > > >Brijesh NK wrote: > >>Could anybody explain SubApplication concepts in struts frame work >> >>Thanks >> >>brijesh >> >>-- >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >Hope that helps, > > >-- >Eddie Bush > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
