Hi, It sounds like you are proposing some utilities that allows a container to be easily assembled. I have tried this a couple of times before in the past but never got round to doing it or failed miserably ;) The difficult is determining what level of abstraction is right.
At one stage I had an AbstractFrontend and an AbstractEmbeddor object that basically did and that was the closest I never finished it. You wanna have a go? On Mon, 11 Feb 2002 05:51, Stephen McConnell wrote: > For me the "real" debate should be about the content of > the framework/component package. I believe that the current > content (ComponentManger etc.) should be depreciated based on > the proposal for framework/service and that the "component" > package should contain the set of "real" component utilities - > utilities that really help with the aggregation of component > management aspects. Note that I'm using the term "aspect" to > focus on a particular behavioural element of a component (e.g. > Contextualization/Parameterization is one aspect, Logging is a > nother aspect, service provisioning and decommissioning is a > third aspect, etc.). For example - a valid "component" package > class would be a real component manager - i.e. something that > provides the bootstrap logging establishment, provides support > for pipelining of components, through respective aspects. I'm > thinking about something totally based on framework interfaces > and default implementations (i.e. independent of Excalibur and > Phoenix). Imagine the sales potential when you are backed by a > tool-set that really adds component integrity to the framework. -- Cheers, Pete -------------------------------------------------- you've made a dangerous leap right over common sense, like some kind of metaphysical Evil Knievel -------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
