This topic is of interest. To me. I started working out with Web Objects. In WebObjects everything you do is basically viewed as an instance of a component base class.
So if you build a search application it can be subclassed and any portion of the model/view/controller can be changed. The java world has yet to catch up to this it seems as we're lost in our mesh of JSP's/MVC frameworks and template engines. If I understand JSF-Java Server Faces is intended to be. Then one could build components that can have inheritance of behaviour. This would lessen the need for sub-applications to support such subclassing. If sub applications are to support inheritance of behaviour there no doubt would be the introduction of a hierarchy which makes this happen and IMHO this is a component model. -Daniel -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 9:42 PM To: Struts Developers List Subject: Re: [Proposal] Sub-application inheritence On Mon, 7 Oct 2002, Eddie Bush wrote: > Date: Mon, 07 Oct 2002 18:19:08 -0500 > From: Eddie Bush <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: [Proposal] Sub-application inheritence > > Sub-applications in Struts 1.1 are one of the biggest advantages over > 1.0. They let you break your configuration apart into multiple pieces - > so that different people can work on their piece of the project without > affecting others. This is good for those of us working in a > team-oriented setting where different (groups of) people may be > responsible for different function areas (ok, Bob and Henry - you guys > get the account-maintenance stuff - Frank, Nancy, and Richardo - you > guys get this 'store' module - etc). Still, sub-applications aren't as > functional as they "could be". > > Because of the structure imposed on sub-applications [1], I think > several people believe it would be reasonable for sub-applications to be > able to share information with one another[2]. I believe it is expected > behavior, in fact. > There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's "single sign on" plus not having to copy your JAR files into things like "$CATALINA_HOME/common/lib" in Tomcat. Sharing *functionality* was not at all in the design goals I had originally. My view of the world was that sub-apps should be as self contained and independent as possible, in the same manner that webapps should be as self contained and independent as possible. The idea is that you can assemble individual subapps together, and also minimize the cross-sub-app dependencies that can complicate and slow down development. Not everyone agrees with this world view. Another, equally important to me, goal is that any existing Struts (1.0) app should be able to run in 1.1 by itself, or as a subapp, with zero changes to the struts-config.xml file. This is where life gets complicated with your proposal. > Currently, each module loads whatever resources it will need. As a > result, there is unnecessary duplication of certain resources. Some of > those particular resources result in wasting RAM, while others have a > more significant impact. Of those that have a more significant impact, > the most notable is undoubtably the data-source. Data-source is handy. > It's a pool for JDBC connections. The fact that you can configure the > pool to limit connections is undoubtably an important functionality to > those who use it (though I can't say with full certainty, as I do not > use the built-in data-source) - but now that we have sub-applications, > determining how to setup the pool to properly manage connection limits > could be quite ... difficult. Yes, there are many very good OS DBMSs > out there - but we all have to sensibly ration out our connections - if > only because of resource consumption. > > The proposal I would like to set forth is thus (this is a suggested order): > 1 - refactor data-source instantiation/acquisition so that > duplicates are not created -- *and* sub-apps would they chain the lookup > from the current module to the default module. > 2 - refactor message-resource instantiation/acquisition the same way > 3 - refactor global-forward ~kind of~ the same way. Global forwards > mentioned in sub-apps would be "pushed up" into the default module. > Yes, I know there's a possibility for clashing. > 4 - (optional) introduce module-level forwards that would replace > our current "global" forwards - and have the exact same "scope" > (visibility) as our current "global" forwards. > All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? > Disclaimer: No, I haven't yet fully studied what would have to be done > to acheive this proposal in it's entirety. I post this for open > discussion so that ideas can be generated and bad ones pruned. > > So, if you take the view that *all* sub-apps are independent of one > another - and should be - obviously this is a very stupid proposal. If, > however, you take the view that all modules are going to be developed in > support of the default module, this is a very logical following (I > think), as it lets you leverage the effort you put into the default > module in your sub-applications. > > My view on (3) above is this: I see modules as being like "classes". > All of the resources are instance-level declarations. "Global", in > this sense, would imply being available either apart from the heirarchy, > or being available in the "base class" (which I suppose puts it back at > the "instance"-level actually). > > We wouldn't break backward-compatability (that I can think of), since > the changes would be primarily geared toward allowing non-default > modules to access the default modules resources. Nothing (that crosses > my mind!) would have to change for the default module (save for > "global-forwards" being "pushed up" into the default sub-app -- this > wouldn't impact a 1.0 app moving to 1.1 in the slightest). > Fundamentally, your proposals change an individual struts-config.xml from being a self contained description of a module to a *partial* description of a module that cannot be installed and run by itself. Personally, I'd rather spend a couple of hundred extra bucks for a few more megabytes of memory than to suffer the complexity costs of this. > I suppose, since, as Ted observed, we're involved in "feature lock", > this is something that is viewed as an "enhancement" or a "bug" request. > My view is that it is a bug, but I have to admit I'm unsure about what > precise functionality you all expected to have in 1.1. I should > probably go check the release plan :-), but I don't recall anything > supporting this being there -- nor do I recall seeing anything that > would inhibit this being there :-) > > Is this a "post 1.1" thing? Is this even a desirable thing (I believe > it is - what's your opinion)? > Post 1.1 enhancement request. > (Would the changes necessary to implement 1 & 2 really be that > significant? Those are the really important items as I see it.) > It's not so much how big the effort is, it's that you are changing the semantics of how things work in 1.0 and 1.1b2. That's a very significant issue. NOTE - that is not at all to say that it's a bad idea on its own merits. I just think it is not appropriate for 1.1 implementation. > ------------------------------- > > [1] - Sub-app partitioning gives us something like: > > (default) > > / \ > Foo Bar > / \ > Baz Bang > I imagine Martin will like this a lot :-). > > [2] - At least non-default sub-apps to share information from the > default sub-app. From [1], Foo would have access to the default > sub-app's config, as would Bang. > > -- > Eddie Bush > Craig -- 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]>
