Ignore changes in the amount of whitespace
Differences between version dated 2004-09-21 22:53:21 and 2004-09-22 14:15:06
Deletions are marked like this.
Additions are marked like this.
= Component Example =
''Adapted from a thread on the PEAK mail list regarding components for beginners:''
''The following is adapted from a thread on the PEAK mail list regarding components for beginners.''
From http://www.eby-sarna.com/pipermail/peak/2004-September/001778.html :
There has to be motivation for needing to *replace* certain components with others, like putting a bigger power supply into a microwave oven to support a bigger cooking compartment. The possibility of replacement is one of the biggest motivating factors in determining how responsibilities are separated into components.
= Questions and Answers =
''Regarding building components and ways to think about 'binding.Obtain' and 'binding.Make'.''
From: http://www.eby-sarna.com/pipermail/peak/2004-September/001778.html
'''Q:''' When would I choose Make over Obtain? and vice versa?
'''A:''' Obtain can access the "binding" system, the "configuration" system, or the "naming" system, depending on what argument you give. As a general rule, accessing the binding or configuration systems will cause Obtain to provide existing components, and accessing the naming system will produce a new component. But there are exceptions, especially since you can create your own 'binding.IComponent``Key' implementations for use with 'Obtain', and they can do whatever you want.
Make, on the other hand, generally means, "make me one of these". But again, you can create your own 'binding.IRecipe' implementations that do whatever you want, so there are exceptions to that rule as well. You can also apply 'Make' to any function or lambda, so the possibilities of what it can do are endless. In a way, 'Obtain' is a specialization of 'Make' that just looks things up instead of making them.
''From a question to the mail list about adding component children at runtime and related configurations.''
From http://www.eby-sarna.com/pipermail/peak/2004-September/001746.html :
'''Q:''' I would like to add Component-children to a component at runtime, as well as advertise those components to other children under certain Interfaces or configuration paths. How do I do this?
'''A:''' Are the interfaces different each time, or is there a set of N interfaces with N instances that always occur?
If you don't know what interfaces you're using until runtime, then you need to have the parent subclass 'binding.Configurable' instead of 'binding.Component', and you'll use the parent's 'registerProvider()' method to register child components. See 'peak.config.interfaces' for more details, especially IConfigurable and IRule.
''The following tidbit is from the beginning of a thread concerning naming.lookup() vs config.lookupComponent().''
From http://www.eby-sarna.com/pipermail/peak/2004-June/001541.html :
'''Q:''' What is the difference between root.lookupComponent() and naming.lookup()?
'''A:''' By default, anObj.lookupComponent() "suggests" to the found component that 'anObj' is the found component's "parent" component.naming.lookup() just looks up the object in question.
'''A:''' By default, anObj.lookupComponent() "suggests" to the found component that 'anObj' is the found component's "parent"; component.naming.lookup() just looks up the object in question.
