struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Leland <>
Subject Re: Compartmentalization of Modules (was Re: [18111] et al)
Date Wed, 21 Jan 2004 03:48:37 GMT
Joe Germuska wrote:

> At 3:30 PM -0500 1/20/04, Edgar P Dollin wrote:
>> If the use of modules is truly to split struts-config.xml files, then 
>> isn't
>> it simpler to just use comma delimited configuration files in web.xml?
> Well... yes.  Some times you just do things the way you've always done 
> them until someone points out a good alternative.
> Actually, on a current project, we're using modules for more than 
> that, but still don't have the sense of strict compartmentalization 
> that comes with the original module design.  The multiple modules is 
> mostly just a way to have multiple "unknown" action configs -- we 
> might be able to use the relatively new wild-card mappings along with 
> a list of config files to get what we need, but this is a temporary 
> approach for prototyping, so it will probably be moot sooner than later.
> I still wouldn't mind someone's description of a case where strict 
> separation of modules is necessary, just so I'll recognize it if I 
> ever come across it myself.  Maybe it's just a matter of taste, as I 
> prefer to build for permissiveness than restriction (as noted in the 
> other thread about requiring form beans for the html:form tag.)

I always thought that the design of Modules had two seemly opposed goals:
1) To write essentially independent modules page navigation, etc...
2) but that can share session data that is produced.

If a module is not meant to be reused then maybe multiple configs would
be a better solution. The independence comes in page flow, and being 
aware of the other applications.
The questions is how can be design  Modules so they reduce spagetti code 
in both page flow
and java code.
What we need is the equalivent of Unix pipes or Web Filters
Maybe the default module can be used to the same effect, acting as the glue.
Using the main module to forward requests back and forth might be a little
overhead in programming maintance. It would also keep the messy dependancies
in just one module the default.

> Joe

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message