Just thought I would chime in as another developer that finds the idea of a hierarchy of modules most useful. Hopefully you don't find my comments to verbose.
My company has decided to move forward with using Struts for one of our applications that is being migrated from a client-server app to a web-based app. It was obvious that we would benefit from using the Struts framework. We created some prototypes to prove its usefulness and see if it could handle some specific customer requirements. While creating some prototypes we wanted to leverage the sub-apps that Struts 1.1 provides. We found, however, that the default module did not behave as we expected. We assumed that if we used messages or errors (bean:message and html:errors) within a sub-app and the message was not found in the message resources for that sub-app, that Struts would look to the default app for the messages. We did not like the idea of duplicating messages across all sup-apps. For example, most all of our modules will be using messages for our buttons like Save, New, Cancel, Delete, etc. (we are using i18n so it's not feasible to hard-code these). We wanted to define these once in the message resources for the default app and override the message in the sub-app as necessary. We have since extended the framework to handle this scenario since we also needed to fulfill a customer requirement that allows the customer to switch between customer-defined labels and system-defined labels. We haven't extended the framework to deal with global forwards in the same fashion yet, but I'm sure we will need to do so as well. So, in short we would love to see the hierarchy of modules idea apply to sub-apps. Russ -----Original Message----- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 14, 2002 4:53 PM To: 'Struts Developers List' Subject: RE: [Core] Truly global globa-forwards The issue here is the model for module usage. The current design came about primarily as a solution for the problem of development scalability. On a large project, having several people making frequent changes to struts-config.xml gets out of hand rather quickly. Breaking the application into modules allows multiple teams to develop their modules independently. The usage model is multiple independent modules that have little or no communication between them. All modules are treated the same, with the default module's *only* distinguishing characteristic being the lack of a prefix. The existence of a default module is primarily for backwards compatibility reasons. It has no special status in a Struts app. This is quite different from the usage model that I needed for my web app, and I think from what you are looking for too. What I needed is a hierarchy of modules. The root module is two things - a framework into which the remaining modules are plugged, and a set of shared behaviours useful to those other modules. To build this, I needed to extend Struts in several ways so that I have a comprehensive hierarchical model. The reason I referred to using the default module for "truly global" forwards, by itself, as hacky is because it confuses the usage model. The modules are no longer independent, per the current design, but they don't form a true hierarchy either, because all the other pieces needed for a fully hierarchical application are missing. Ultimately, what we want to do is collect information on how people are using modules, and how they want to be able to use them, and think through the design issues of the various usage models. Then we'll be able to take a more comprehensive look at how we might incorporate multiple models into the Struts code base. To respond to a couple of other points you made: * I can't put my code into contrib, sorry - it belongs to my employer, not to me individually. * Forward patterns were added for 1.1-b2. It's mentioned briefly in the release notes, but the only real description is currently here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10268 Note, however, that $A was subsequently changed to $M. -- Martin Cooper > -----Original Message----- > From: Eddie Bush [mailto:[EMAIL PROTECTED]] > Sent: Saturday, September 14, 2002 12:04 PM > To: Struts Developers List > Subject: Re: [Core] Truly global globa-forwards > > > (this started on struts-user -- see thread of same name there for > background) > > Martin Cooper wrote: > > >I can't say for sure whether this is likely to become part > of the Struts > >core or not. However, what you are asking gives us another > data point on the > >way modules are going to be used in Struts 1.1 apps. > > > I think it's very logical that you would have the ability to > make use of > a "global" configuration (of most things) in addition to the > sub-application configuration (data-sources, properties, you > name it). > Craig, for compatability reasons I'm sure (and to simplify > things too, > I'd wager), made the application root yet another sub-app -- > and I think > that's the key thing that disables "global" configuration. > Ideally, I > think you're right -- those values specified for the > "default" sub-app > would be the ones chosen -- and then wouldn't have to be > specified per > sub-app. That would enable better management of constrained > resources > (like database connections, etc), since all sub-applications > would share > one resource (It's my understanding each sub-app would > acquire it's own > pool. That being the case you'd have to "gamble" a bit on how you > configured things such as data-sources --- so you would not > exceed your > allotted connections). > > ... but would that perspective really break anything? ... wrt > backward-compatability, I mean. I really should better familiarize > myself with the code and think this out better... > > >I have actually done something along those lines, if not > exactly what you > >are suggesting. I have an app in which the default module > acts as a kind of > >framework into which the other modules are plugged. So, to use your > >terminology, the "truly global" global forwards are those > defined in the > >default module. > > > Yes, upon further thinking, I like this. > > >To make them accessible to all other modules, I wrote my own > extension of > >ActionMapping and overrode findForward(). My findForward() > looks first at > >local forwards for the current module, then global forwards > for the current > >module, and finally, global forwards for the default module. > > > ... local forwards for the current action, I think you mean. > Yes, that > would be the intelligent way to do it I believe. This would be > facilitated by the default module's config being stored in the > application's scope, I presume. You should clean your > implementation up > and post it in contrib ;-) > > >I should note, though, that my app makes several other > extensions to Struts > >to really make the default module a framework. By itself, the way I'm > >treating "truly global" forwards is rather hacky. > > > I don't know why you'd say that ... but I haven't seen your code ;-) > Sounds good to me. > > >If you wanted to do something like this but take the "truly > global" forwards > >from a separate XML file, you could borrow some Digester > rules from Struts, > >and write a very simple PlugIn which loads them up and stores them in > >servlet context. Then you could write your own extension to > ActionMapping, > >similar to mine, but, for the last step, looking in the > "truly global" > >forwards your PlugIn stored in the servlet context. > > > No, upon further consideration, I think I like the solution you > presented better. It really is a logical following to > things, I think ... > > >One note, though: You'd have to be careful if you're using > forward patterns > >in your "truly global" forwards, since the resulting URL may change > >depending on the module from which it is invoked. > > > I don't understand what you're saying here -- forward patterns? That > must be something I haven't fooled with ... > > My global forwards (the ones I view as *truly* global) are all > context-relative, and ... I don't see any possible danger using them > everywhere. Maybe I'm missing something here? > > >-- > >Martin Cooper > > > Eddie > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
