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 with 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. -adam k. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
