> From: Marcus Crafter [mailto:[EMAIL PROTECTED]] > > > On Thu, Jun 13, 2002 at 09:12:27AM -0400, Berin Loritsch wrote: > > Marcus, we have talked about many different details over > the past few > > days, and I must say, I can't remember the conversation > that your code > > addresses. Can you please provide a pointer? > > No problem. I understand everyone's focusing on A5 atm. > I've been > following the conversations with much excitement. The first > mention of custom markers by myself is available here: >
The crux is you need to extend the lifecycle. Just out of curiosity in what ways do you need to extend the lifecycle? The fact that you can do it does not negate the fact that you are tying yourself to a certain container. The core problem is the contract between a component and a container. Currently, any Avalon Component should be able to function in any compatible container. The problem with extending the lifecycle is that you introduce new contracts that are not required to be enforced by other containers. Playing devil's advocate, what happens if someone royally screws over your favored container? Or what happens if the container you are using falls out of favor? You have to alter another container--or create your own. The only way to effectively enforce your contracts on lifecycle is to create your own container and maintain it. Fortress was designed with hierarchical containers in mind. In order to provide fast and easy customization on a component's lifecycle we need to be able to plug in our own ComponentFactory that manages the startup/destruction phases of a component. I think that is more effective, less intrusive, and more stable than a callback mechanism. It is not that easy to enforce the proper order, or same order on a component's lifecycle when it is extended in this way. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
