Provider, ContainerProvider, Composite Pattern
By ajitsabnis on Aug 05, 2006
PAPI = Provider API, a public interface in PS6/7.
I would like to consider just two interfaces from PAPI: Provider and ContainerProvider. These two form the basis of PS aggregation such that ContainerProvider allows aggregating content from more than one Provider. The two interfaces can be pictorially presented as follows:
Note that this is a simplified representation for discussion purpose.
Provider is first class citizen of PS6/7 that presents content, edit, help, etc "views". ContainerProvider is the mechanism that manipulates two sets of providers; available providers "can be selected" for presenting content view in client browser.
ContainerProviderAdapter, the supposed to be root of all ContainerProvider implementations, extends ProviderAdapter. The aggregation engine, PS6/7 Desktop logical component, works with the "top level" or "default" container-provider to give back response to client's request. The top level container can contain another container, e.g. SamplePortal has top level container as tab container, and the default selected tab containing a table container. That is, Desktop effectively allows building a tree of collaborating providers ("parts") and container-providers ("whole") to present PS page.
Consider GOF Composite pattern with four collaborators: Component, Composite, Leaf, and Client. With what we have in PS6/7 Desktop, I can say Provider is Leaf, and ContainerProvider is Composite. There is no Component interface per say! Component interface would be what we've in ContainerProviderAdapter class. That's why I can say Desktop uses Composite pattern albeit implicitly or indirectly. Desktop as a Client knows about Leaves, that's all.