Along similar lines, I have a question of using modules for internationalization. We have a requirement to not only support i18n, but to be able to tell the client how many of their visitors are seeing which language version of any particular web page. I had thought of using modules to help keep message resources and to generate URLs that contain the language information. Is there a better way to track such information?
Bryon > Some people prefer to stay away from modules (I have a vague memory of at > least one Struts committer saying they generally try to avoid them for > example). One option that Craig turned me on to (and I hope I'm > remembering this right!) is using entities to import XML into another. If > the only real purpose of using modules is to better organize your multiple > struts-config files and tiles-defs, this might be a good answer. > > <!ENTITY struts_config_2 SYSTEM "config_files/struts_config_2.xml"> > ... > &struts_config_2; > > That, more or less, functions as an import, as I recall (someone PLEASE > correct me if I got the syntax, or the concept of course, wrong). > > Of course, if you have another purpose for modules, like if you have a > desktop CRM application that has a number of largely independent > sub-components (I picked this example because we're discussing this very > thing right now), then they might be a good fit. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > > On Tue, October 11, 2005 4:36 pm, Preston CRAWFORD said: >> I've done this in the past. Used modules to logically (and for the sake >> of having sane config files) break up these config files. However I'm >> wondering if anyone avoids using modules and maybe merges the files >> using ANT or something? Reason I ask is because I know there are >> pitfalls to using modules and I'm not sure I want to have to deal with >> them for this project (pitfalls like switching between the parent and >> the module, pathnames, etc.). >> >> Preston >> >> --------------------------------------------------------------------- >> 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]
