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!"
Joe
At 16:58 -0400 8/6/03, Sgarlata Matt wrote:
Found the thread...
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08910.html
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 modules.
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 days. - 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.
Matt ----- Original Message ----- From: "Robert Leland" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, August 06, 2003 4:14 PM Subject: Re: Resource Bundle Prototyping
adam kramer wrote:> >>it's clear that many people intuitively expect modules to be less
>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,with>>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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
