struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: Module Inheritance Revisited
Date Wed, 06 Aug 2003 21:07:26 GMT

This does sound like kind of an abuse of modules (if you'll pardon the term...)

Shouldn't all of that structure be a layer separate from Struts?  It 
seems to me as if "knowledge items" should be part of your data 
model, not tangled up in Struts/Controller-View structures.

Further, I would suggest that if you are going to have trouble 
"finding actions after a few days" then maybe you're using actions in 
a very... er, idiomatic way?

I think Struts is very flexible, and I think it's great to try to 
make it more so, and I won't even say that it's foolish to hope that 
Struts could be as flexible as to fit your model -- but wooo-eee, 
you're pushing it to the limit!  I'm hearing Mr. Scott... "she canna 
take no more, Cap'n!"


At 16:58 -0400 8/6/03, Sgarlata Matt wrote:
>Found the thread...
>So 1.1 is out now, and people are using Struts modules.  Someone said they
>wanted to hear how Struts users use 1.1 with modules, so here goes.  I think
>Craig will cringe if he reads this ;)  The application I work on is a
>knowledge management application with many different developers working on
>it.  Each "knowledge item" in the application gets its own module (let's
>call it a "knowledge module").  For example, a knowledge item might be a
>"document", or a "project".  There are also "functional modules", such as
>"related links" or "data access" which allow the user to relate a document
>to a project, or assign access rights to a knowledge item, respectively.
>The knowledge modules are pretty self-contained.  The functional modules get
>pretty tricky to implement since they want to access stuff in the knowledge
>modules.  For example, when you link a document to a project you want to
>start from the document and then search for the project using the standard
>search interface for projects.  This means some tricky routing to different
>So if I'm having all this difficulty with functional modules, why bother
>with modules at all and not just make the entire application one module?
>Well, here is the reasoning I've used:
>- Each module is in its own directory and each module has few files
>associated with it, so a junior programmer can get familiar with all the
>files for a single module and feel like he or she "knows" that module.
>- There is less source control contention for configuration files because
>few changes need to be made to the web.xml file and the default
>struts-config file.
>- Module information is grouped together logically, and there is no way to
>mess it up.  Ideally if we had one struts-config file people would group
>things logically by module, but the reality is people are lazy and will (for
>example) just put their newest <action> element at the end of the
><action-mappings> and it will be impossible to find <actions> after a few
>- All the files for a module can be easily copied to another application and
>customized for that application's needs because they are grouped together
>(the JSPs have their own directory, and the complete configuration for the
>module is in the WEB-INF directory).
>Well I'm about out of reasons, maybe I was just using modules because they
>were there ;)  Honestly if I was the only person working on the project, the
>added complexity of modules wouldn't be worth it and I would just use a
>single module.
>----- Original Message -----
>From: "Robert Leland" <>
>To: "Struts Developers List" <>
>Sent: Wednesday, August 06, 2003 4:14 PM
>Subject: Re: Resource Bundle Prototyping
>>  adam kramer wrote:
>>  >On Wed, 6 Aug 2003, Joe Germuska wrote:
>>  >
>>  >
>>  >>I'm pretty sure this was an explicit design intention, although the
>>  >>main reason may have been to make backwards compatibility more
>>  >>manageable (or maybe not -- I can't cite any place where this was
>>  >>discussed; I just have vague recollections).  From reading the lists,
>  > >>it's clear that many people intuitively expect modules to be less
>>  >>walled off from each other.
>>  >>
>>  >>Maybe a smarter Modularization, but one which might break some
>>  >>compatibility, could be targetted for a 1.5 release, or some
>>  >>mid-point between 2.0, which has a lot of bigger changes marked for
>>  >>it.
>>  >>
>>  >>
>>  >
>>  > I am going to make an effort to look through the archives and find the
>>  >reasoning behind the design of the current modules (unless someone out
>>  >there can enlighten us all). And explore the code and docs to come up
>>  >some ideas for application-wide module features that won't break struts
>>  >conventions, etc... The modules would be much more useful to me if they
>>  >had a concept of "application" and module.
>>  >
>>  >
>>  There were some thoughts about module inheritance that were discussed
>>  last summer.
>>  To my knowledge though no real design work has been done. It does seem
>>  that resource
>>  inheritance is the #1 requested feature.  There may be a Bugzilla
>>  enhancement request ticket
>>  on this.
>>  -Rob
>>  >-adam k.
>>  >
>>  >
>>  >
>>  >---------------------------------------------------------------------
>>  >To unsubscribe, e-mail:
>>  >For additional commands, e-mail:
>>  >
>>  >
>>  >
>>  >
>>  >
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Joe Germuska       
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

View raw message