NU-CCS-99-04.ps [ Readme | Copyright | Tutorial | Download | Feedback ]

Manipulation and Representation of Context Beans

  The essence of the runtime containment and service protocol [9] is that (BeanContext) beans may be placed in (and removed from) their enclosing BeanContext bean. The BeanContext hence becomes a container of objects, which not only establishes a logical hierarchical structure, but also provides to its inhabitants a service discovery (and obtaining) protocol. In this section we describe how new support for runtime containment and service protocol can be seamlessly added to the BeanBox.

In order to test beans implementing the BeanContext interface in a visual development environment, the beans need to have some kind of visual representation. Without such a representation, it would be impossible to manipulate them visually at assembly and design time.

Several difficulties arise. When a new ContextBean is added to the BeanBox there is the question of how to represent that bean visually. The visual representation can be provided either by the bean author or by the development environment. Moreover, the bean can be a BeanContextProxy and itself a visual container (extends java.awt.Container). In that case, there are two hierarchies to maintain and a possibility for inconsistency between the two.

The BeanBox distinguishes (when visual representation is concerned) only between visual beans (that are a kind of java.awt.Component) and non-visual ones. A non-visual bean is represented by a special label object (an instance of sun.beanbox.OurLabel), which displays the bean's name. When hide invisible beans mode is selected or design mode is disabled , the labels representing non-visual beans are hidden. When enhancing the BeanBox with support for runtime containment and services protocol, there is also the BeanContext or BeanContextProxy case to consider.

Every bean can have a Component or Container, and/or a BeanContext, associated with it. A bean can establish that relationships either through inheritance by extending one of BeanContext, Component or Container classes, or by being a BeanContextProxy or a BeanContextContainerProxy or a BeanContextChildComponentProxy for that object.

There are 6 combinations to consider, for each we offer a different policy concerning the visual representation:

• A visual component but not a context composite. A bean, which is a Component but not a BeanContext, bean should always be represented (both in design time and runtime) by the Component associated with it. This behavior would be consistent with the behavior in the original BeanBox. No beans can be placed inside this bean. It is neither a visual nor a context container, and therefore the visual representation should be used.
• Neither a visual component nor a context composite. The original BeanBox covers the case of a bean which is not a Component and not a BeanContext. At design time, a special label represents a non-visual bean, which is hidden at runtime mode. No beans can be placed inside this bean.
• A visual component and a context composite. A bean can be both a Component and a BeanContext. However, this is an unnatural case that probably ought to be disallowed. It is unnatural because the bean seems to have a contradictory behavior, i.e., as a leaf (Component) in the visual containment, and as a composite, a collection (BeanContext), in the runtime containment hierarchy.

  A possible work-around is to represent such beans at design time by a special container (e.g., OurContext, analogous to OurLabel) which will allow the user to add beans into that BeanContext, and at runtime by the Component associated with it. Beans placed inside this bean should be added to its special container and also to its BeanContext.

• A visual but not a context composite. A bean, which is a Container but not a BeanContext, is a common case, typically coded by a user who did not anticipate runtime containment. This kind of visual bean should always represent itself visually. Still there is a hidden catch. If the user places inside this bean other beans that expect services from a runtime environment, then those beans must be added to that container and to the runtime context of some other bean.

  Even if it were possible to somehow manage this behavior, it is still too confusing to work with. Therefore, every bean that is a Container but not a BeanContext should be automatically associated (in the extended BeanBox version) with a BeanContext. Every bean contained in the container is should then also be added to that BeanContext, which would propagate the environment services according to the protocol.

• Both a visual and a context composite. The simplest case is a bean, which is a Container and BeanContext. The bean should always represent itself, and there are no additional problems. Beans placed inside the component should be added to both the Container and to the BeanContext, either by the bean itself or by the ContextBox environment.
• A visual composite but not a visual component. Impossible. No bean can be a Container and not be a Component, since Container extends Component (as in the standard COMPOSITE pattern [23]).

NU-CCS-99-04.ps [ Readme | Copyright | Tutorial | Download | Feedback ]