> -----Original Message----- > From: Bailey, Shane C. [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 13, 2003 3:01 PM > To: 'Struts Users Mailing List' > Subject: RE: using modules versus simply using multiple struts-config > files > > 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.
I do plan to use Validator and you are right. I just checked and the commons version of validator that shipped with Struts 1.1 doesn't allow for the "bundle" attribute. Coincidentally, it appears that the DTD (and I assume the related source code too) in the commons validator project were updated within the last week to add the "bundle" attribute. So, I could probably pick this change up in a recent nightly build of the commons-validator.jar. Unfortunately, I can't use nightly builds of anything in my project. It was hard enough for me to get approval to use the 1.1-b2 release of Struts for a project last year. It worked out great by the way. WebApp has performed flawlessly in production since December of last year. I'm not even going to try to get approval to use an open source nightly build. :-( Which leads me to my next question. Are there plans for an official release of an updated commons validator module that could be used with Struts 1.1 where I'd be able to use the "bundle" attribute any time soon? I'm not expecting an answer to that question on this list. I think there is a separate commons-user list or some such thing like that where I will have to direct that question. In the meantime, I'll have to put all my field name prompts and any validation messages in the default resource file. This was exactly the kind of info I was looking for. Thanks, Van > > > -----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 <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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
