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]>
