Whichs phases a container should exposes to enable developers to hook up and extend the lifecycle of components?
For now, we haven't really gotten that far.
I thought about supporting
- Creation (after instantiation?) - Configuration (before configure???) - Destruction (before dispose)
Thoughts?
Are you referring to the lifecycle of the container itself? It's not clear. It looks as if you are wanting to duplicate the Lifecycle Extensions which we have in Java. I don't think that is how we should think about container extensions.
To manage extensions I created a LifestyleManager class that exposes events. I would like to enable Context/Contextualization in Avalon.Net through extensions as an eat-your-own-dog-food exercise.
Anyway every ComponentFactory should rely on LifestyleManager class as a handler. I don't know how to do that in a non-
intrusive way and not dependent of a correct ComponentFactory implementantion to everything works fine. Help!!!
The first place to start is the simple case. Start with what you _know_, not with what you're not sure about. While it seems like obvious advice, let's look at what we already have defined.
1) A container is responsible for the life of a component, and satisfying any and all dependencies.
2) A container is responsible for any aditional features that can be bolted onto an existing component.
The obvious point to start with is the first one. If you can get a component loaded, and verify that all its dependencies are also loaded, then you have a workable foundation.
From that point forward, we start to look at creature features. What would I like to do with my existing components that would help development, debugging, management, etc.
From thinking on those types of features, we would think on how to accomplish those features.
For example, with the Instrumentation package, we can most likely bolt on certain types of instrumentation without ever getting into the implementation details of the component. For example, how often is a method called, or how long does the method take to process on average? When we have identified a feature that we know we will use in the near future, we can then look at what is available to implement that.
Up until this time it is completely premature to define interfaces and how they interact. We simply don't have the appropriate information.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
