RE: using modules versus simply using multiple struts-config file s
> -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 tag instances that used the "report" module resource file like so: I am inferring this from the main Struts 1.1 example application where an "alternate" resource file is accessed like so in logon.jsp: 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 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: 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 > > &
RE: using modules versus simply using multiple struts-config file s
I think if you are going to use messages like that then one place you may run into problems is with the Validator. I can't remember if not all or none of the elements in the Validator (which had the "key" attribute) didn't have a "bundle" attribute (so I don't know how it would determine which bundle to look up and I can't imagine it goes through every one automatically). At least I ran into a problem when I first started using Validator and attempting something similar. If you are not using Validator (or it works differently now or I just was not using it right) then disregard, of course. -Original Message- From: Van Riper, Mike [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 5:55 PM To: '[EMAIL PROTECTED]' Subject: RE: using modules versus simply using multiple struts-config file s > -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 tag instances that used the "report" module resource file like so: I am inferring this from the main Struts 1.1 example application where an "alternate" resource file is accessed like so in logon.jsp: 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 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: 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 acro
