Peter Royal wrote:
On Monday, January 27, 2003, at 09:37 PM, Stephen McConnell wrote:Block <-- extends Appliance by (a) doing additional management of its implememntation (where block implementation referes to the components heirachy it is managing), and (b) publishes services established via the implementation as dynamic meta info - i.e. a block transforms itself into a normal component in that it exposed depedencies and services and can be applied as a solution when building other components. Implemntation of (b) is currently in-progress.
Could one extend a Block to provide a "layer" between its interface as a component and the components that it manages?
This is the direction I thinking about. Basically I would to be able to plug in a block controller. The controller would then be responsible for (a) the internal implementation - components and sub-containers, etc. - and the (b) service provision strategy. This is currently handled as part of the block implementation but I would like to move to pluggable controllers once the block == component loop is finished.
I like the layout (finally starting to pay more attention, head coming up above the chaos). I'm concerned about the terminology of 'Appliance' though.
I really like it!
Did you pick appliance in that a kitchen is made up of various appliances? (Appliance to me brings up images of microwaves, dishwashers and refrigerators).
Nope.
An appliance is something you "use" to achieve a result - it is a tool that helps you do something to something. E.g. a washing machine washes clothes. The thing of value is the clean clothes. The washing machine is tool that you plug into your infrastructure to help you do that task.
* You plug an appliance into a containment environment.
* The appliance cooks a component.
* Different appliances can do similar this in different ways
(e.g. the default implementation uses meta information as its
strategy for cooking the component). A block uses nested
appliances to cook a container.
While they are the (building-)blocks of a kitchen, I would think that the relationship would be inverted, an appliance is a block. Just as shelves, counters, cookbooks, utensils are also blocks, but not appliances.
I consider an appliance appropriate for micro-scale component management. On the other hand a block is macro. Keep in mind that I'm staying very close to the Cocoon functional requirements when I refer to block - which is different from the Phoenix term. Phoenix notion of Block is a collection of classes + single meta info definition. This is equivalent to the Assembly/Merlin definition of a component type.
Could a merlin block be used directly as a phoenix block? -pete
Yes - providing Phoenix was updated to recognize that it is dealing with a dynamic component type.
In the case of block to component transformation, the container needs to recognize that the component type meta info is only the meta info about the construction of the blocks - its not the meta info of the block as a component. To get the component model the container has instantiated the block (which is independent from instantiation of the blocks implementation) and then get the block-as-component-meta-model from the block. Nice and clear isn't it! This means that the container needs to recognize the difference between a static component type and a dynamic component type.
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
