> -----Original Message----- > From: Bailey, Shane C. [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2003 12:02 PM > To: 'Struts Users Mailing List' > Subject: RE: using modules versus simply using multiple struts-config > file s > > Very interesting. I didn't know you could now have multiple > struts-configs > and no modules. > > The two problems I had with using modules was (at first) the switching > between them as mentioned. I never took to the SwitchAction > so I use global > forwards which do my module prefixes for me. And second, having to > duplicate my (commonly used) messages in each modules > resource file (this > problem is more of a problem of "why can't I inherit them" > than anything > else. > > It seems like multi configs with no modules solves problem 1. > I take it > that you will still have problem 2. But I did see a post > recently about > someone who made a code change so that resource files could inherit.
My current plan is to have the default resource file contain common resources shared by all my modules (here I use "module" to refer to a subdirectory of my web root that has its own separate struts-config file for action mappings, form beans and anything else specific to that subsection of the webapp) and then have a separate resource file associated by module name with each specific module. A person working logically in only one module would access their module-specific resources using the module name and any common resources in the default manner that doesn't require specifying the name associated with the resource file in the struts-config file configuration for it. I am planning to have one struts-config for common configuration and a separate struts-config for each major subsection of my webapp. The common resource file configuration goes in the common struts-config file. The resource file specific to each subsection of the webapp would be configured in the separate struts-config file for that subsection. I think this is where one of the differences in my approach comes in. I believe each module can have its own default resource file configuration that can be different when modules are configured separately in the web.xml file. Since I don't use separate web.xml entries, I can only have one common default resource file configured across all my logical modules. This just means that for most resources, I will be specifying the module resources file by its associated configuration name as a parameter to my resource file property lookups. Since there will be a direct one-to-one mapping between each subsection of the webapp and the resource file specific to that subsection, I think this will be something that will be easy to remember. For example, a logical "report" module would specify the "report" bundle in <bean:message> tag instances that used the "report" module resource file like so: <bean:message key="report.header" bundle="report" /> I am inferring this from the main Struts 1.1 example application where an "alternate" resource file is accessed like so in logon.jsp: <bean:message key="prompt.password" bundle="alternate" /> I think you should be able to do the inverse of this when using separate module configurations. For your module related property lookups, you could use the default resource file configured for that module. For the common ones that you wanted to use across all modules, you would have a configuration entry for the default resource file in each module struts-config file and make that your alternate resource file for the module. So, for you it would be the property lookup of a shared resource that would need to supply the bundle attribute to the <bean:message> tag. Assuming you used "common" as the key for your shared properties, your lookups in the common resource file would be the ones that needed to supply the bundle attribute: <bean:message key="app.copyright" bundle="common" /> This isn't as transparent as a patch to Struts that supports inheriting common properties into the default resource file for each module, but, it would allow reuse of common properties across multiple modules. At least, this is my understanding of how it could work. I haven't tried modules yet. So, I can't be certain of that. > Sadly, since I am using modules, I can't think of any > advantages of modules > if you can have multiple struts config, tiles def and > resource files and no > modules. > > -----Original Message----- > From: Van Riper, Mike [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2003 2:02 PM > To: List Struts-User (E-mail) > Subject: RE: using modules versus simply using multiple > struts-config files > > > -----Original Message----- > > From: Van Riper, Mike > > Sent: Tuesday, August 12, 2003 5:55 PM > > To: List Struts-User (E-mail) > > Subject: using modules versus simply using multiple > > struts-config files > > > > > > I did search the archives and there is information about > > using multiple > > config files and separately about using full-blown modules > > too. There may > > have been a comparison of the two approaches somewhere in the > > archives too, > > but, I was not able to find it. Thus, my reason for posting > > this to the > > group. > > > > I'm setting up the webapp infrastructure for a new project. > > This is the > > first opportunity I have to use the new module support in > > Struts 1.1. As I > > am investigating it, it seems like the new capability to > > specify multiple > > struts-config files in your default module configuration in > > the web.xml file > > gets you most of the modularity advantages that multiple > > modules provide. > > > > Sure, you do get to leave the module leading subdirectory out > > of your action > > mapping definitions when you define separate modules in > > web.xml for each > > struts-config file. Other than that, I'm not seeing the > > advantages of using > > full-blown modules when I could just setup separate > > struts-config files for > > each logical module. On the flip side, you have to deal > with properly > > switching between modules when you use modules. Also, every > > request must go > > through an action mapping to use modules. > > > > Right now, I'm leaning towards setting up separate > > struts-config files for > > each logical module and simply specifying them as a comma > > separated list in > > the default module configuration in my web.xml. This is a > > relatively small > > webapp which can be logically partitioned in to about 5 > > areas. Also, there > > will be three of us working in parallel on a tight schedule. > > So, it seems to > > me that I get the modularity benefits without the module > > restrictions by > > simply setting up separate struts-config files. > > > > Before going too far down this path, I was interested in any > > feedback from > > others on the list about this approach. Am I missing > > something about the > > differences between these two approaches? > > I love talking to myself. ;-) > > I know that setting it up with separate modules in web.xml > can be made to > work, but, I've also seen recent postings about difficulties > using tiles and > difficulties switching between modules by other module > newbies. I'd rather > not have to deal with that myself let alone training the other Struts > newbies on my current tightly scheduled project. So, I guess > I'll go ahead > with my current plan to use multiple struts-config files > associated with one > entry in my web.xml file. The way I'll be setting it up makes > it easy to > switch to true separate module definitions later on anyway. > Each logical > module will already have its own subdirectory below the web root. > > Based on other suggestions I've seen, I'll have a default > struts-config file > for shared configuration of plug-ins (e.g., tiles), global forwards, > controller, etc... In addition, a separate struts-config file for each > logical module. > > > > > - Van > > > > Mike Van Riper > > mailto:[EMAIL PROTECTED] > > http://www.baychi.org/bof/struts > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
