## Passing arguments to a part

A parent passes arguments to its children using a ContainerContext. The context can pass arguments to the constructor of a part or specify a factory for constructing those arguments. For example, a particular ContainerContext might specify rules like:

- If the child asks for an INameable, use object X;
- If the child asks for an IActionBars, construct one using factory Y;
- If the child asks for any unknown type and object Z can be adapted to that type, return the adapter;
- If the child asks for a dependency that can't be satisfied in any other way, redirect to some other context.

If the context doesn't supply a particular dependency, the child will use the default implementation from the org.eclipse.core.component.types extension point. Since the context can override any of the arguments a part gets in its constructor, the parent can override any of the interfaces the part normally obtains from its site. For example, the parent could force its child to use a different implementation of IActionBars by supplying an IActionBars in the context.

The parent has several options for constructing the context:

- Provide the child with a specific instance for one of its dependencies;
- Provide the child with a factory to construct one of its dependencies, if needed;
- Redirect some or all of its own dependencies to one of its children;
- Use a multiplexer to dynamically redirect one or more dependencies to its active child;
- Let the child use the default implementation for some or all of its dependencies.

The following DefaultContextView, RedirectContextView and OverrideInstanceView examples demonstrate each possibility.

### Default context

The following example shows the source for a view that creates two nested children in the default context. The fact that the children are created in the default context means that the parent doesn't care about the child's name, toolbar, selection, and so on and isn't prepared to deal with them. If the parent wanted to do something with, say, the current selection in one of its children, it would have needed to pass an ISelectionHandler to that child. The end result is shown below the example.
`/**`
`* View that demonstrates how to create two nested children`
`* with the default context.```````
`*/`
`public class DefaultContextView {`
`public DefaultContextView(Composite parent, IPartFactory factory) throws CoreException {`
`// Create a resource navigator`
`ContainerContext viewContext1 = new ContainerContext();`
`ISite view1 = factory.createView(`
`IPageLayout.ID_RES_NAV, parent, viewContext1, null);`
``
`// Create property view`
`ContainerContext viewContext2 = new ContainerContext();`
`ISite view2 = factory.createView(IPageLayout.ID_PROP_SHEET, parent, viewContext2, null);`
``
`parent.setLayout(new FillLayout());`
`}`
`}`

### Redirecting dependencies from a parent to a child

This example demonstrates how to redirect a site interface from the parent to a child. This composite view contains a resource navigator and a property view. It redirects its selection handler to the resource navigator and it redirects its action bars to the properties view. The result is a view that provides a resource selection and contains the toolbar and menu from the properties view, as shown below.
`public class RedirectContextView {`
`/**`
`* Component constructor. Do not invoke directly.`
`*/`
`public RedirectContextView(Composite parent, IPartFactory factory, ISelectionHandler selection, IActionBars actionBars) throws CoreException {`
`// Create a resource navigator. Redirect the navigator's selection directly to our parent.`
`ContainerContext viewContext1 = new ContainerContext()`
`.addInstance(ISelectionHandler.class, selection);`
`ISite view1 = factory.createView(`
`IPageLayout.ID_RES_NAV,`
`parent, viewContext1, null);`
``
`// Create property view. Allow the property view to use our action bars directly.`
`ContainerContext viewContext2 = new ContainerContext()`
`.addInstance(IActionBars.class, actionBars);`
`ISite view2 = factory.createView(IPageLayout.ID_PROP_SHEET, parent, viewContext2, null);`
``
`parent.setLayout(new FillLayout());`
`}`
`}`

### Providing dependencies directly

This example demonstrates how to supply a child with one of its dependencies directly. In this example, we create a composite view containing a problems view and a properties view. We supply the problem view with an ISelectionHandler in order to display the number of selected problems in the content description. The end result is shown below.
`public class OverrideInstanceView {
/**
* Component constructor. Do not invoke directly.
*/
public OverrideInstanceView(Composite parent, IPartFactory factory, final INameable name) throws CoreException {
ContainerContext viewContext1 = new ContainerContext();
// Add an ISelectionHandler to the view's context. Whenever the view changes its selection,
// display the number of selected items in the content description
viewContext1.addInstance(ISelectionHandler.class, new ISelectionHandler() {
/* (non-Javadoc)
* @see org.eclipse.ui.part.services.ISelectionHandler#setSelection(org.eclipse.jface.viewers.ISelection)
*/
public void setSelection(ISelection newSelection) {
if (newSelection instanceof IStructuredSelection) {
IStructuredSelection sel = (IStructuredSelection)newSelection;
int selectionSize = sel.size();
name.setContentDescription(MessageFormat.format("{0} problems selected",
new String[] {Integer.toString(selectionSize)}));
}
}
});
// Create a problem view
ISite view1 = factory.createView(
IPageLayout.ID_PROBLEM_VIEW, parent, viewContext1, null);
// Create property view
ContainerContext viewContext2 = new ContainerContext();
ISite view2 = factory.createView(IPageLayout.ID_PROP_SHEET, parent, viewContext2, null);
parent.setLayout(new FillLayout());
}
}`