> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > On Wed, 3 Apr 2002, Berin Loritsch wrote: > > > Components (in the formal sense) will always be tied to their > > container. > > I don't know what is the 'formal sense' you are talking about, > but one of the goals of commons is to create components that > are _not_ > tied to a container.
Again, Commons doesn't have 'formal' components. Formal components include CORBA, EJB, Avalon, Servlets, etc. > > The container provides everything to the component. > everything. That > > means not just the logger. That means that the component > is tied to > > the framework anyway. > > And people have a choice to not use this kind of container - the > components we write will work in most containers, if a container have > a problem with pull model ( Log.getLog() ) - too bad for it. Then it's not a component. > > Commons, Sun, and several other people use the term component in an > > informal sense. A component has a *role* (or work > interface) separate > > from the implementation. It is tied to a container, which > manages it. > > Commons has a modular API, and each API group has been given the > > informal name of component, which confuses people who see commons' > > docs and avalon's docs. > > I certainly hope avalon doesn't have a trademark on > 'component' or claims ownership or 'the Right Definition' of the term. Who do you think I am? Of course not. Now I have to dig up my definitions on the net..... :/ > > > Lastly, trying to mix IoC and static access based systems is like > > trying to mix procedural and object oriented programming. > It can be > > done, but it is messy, confusing, and not maintainable. Each model > > has its advantages > > I don't know about IoC, but push and pull models are mixed in most > programs and that's a good and desirable thing. > > If IoC doesn't 'mix', then it shouldn't be used. IoC is used for container managed systems. If you have a hierarchical container system, the parent container controls the direct child containers which in turn control their children. The reason it *shouldn't* mix is because of security reasons. If a sub- container's security were breached, the damage that can be done is limited to that smaller container. There are more reasons, but that is the most important. Therefore it is usually relagated to server systems. It forces you to think differently, and is a useful tool in that respect. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
