Owner, Container, Parent

Overview

This document introduces the key concepts of owner, container, and parent, which describe three types of relationships that may exist between one Enyo object and another.

For the sake of discussion, let's consider an Application object that creates a ConfirmDialog and places a message inside of it, like so:

components: [
  {kind: "ConfirmDialog", components: [
      {content: "Are you sure?"}
  ]}
]

Owner

The ConfirmDialog and Content objects are part of the Application, and we say the Application owns those objects. The Application object contains logic that interacts with ConfirmDialog and Content to get its work done. This arrangement helps to advance one of the Enyo framework's key goals--for the Application to have the simplest view of the system. The job of the Application is to concentrate on implementing program logic without worrying about the details of data processing.

We can outline the system from the Application object's viewpoint like so:

• Application
  • ConfirmDialog
  • Content ("Are you sure?")

Here's a diagram showing what the UI might look like:

In the diagram, the orange-shaded objects are owned by the Application and the blue-shaded ones are owned by the ConfirmDialog.

Notice that the ConfirmDialog has its own components, such as ClientArea and OkButton. These aren't mentioned in our outline of objects owned by the Application because they are, in fact, owned by the ConfirmDialog. As noted earlier, the Application object should not know any details about how the ConfirmDialog is implemented.

The ownership structure of the ConfirmDialog may be outlined like so:

• ConfirmDialog
  • ClientArea
  • BottomBar
  • CancelButton
  • OkButton

Just like the Application, the ConfirmDialog need only concern itself with those objects it owns. Everything else is hidden by encapsulation.

(Note: You can think of object ownership in terms of scope, but be careful not to get object ownership scope in Enyo confused with variable scope in JavaScript.)

Here is the complete ownership tree from the framework's perspective:

• Application
  • ConfirmDialog
    • ClientArea
    • BottomBar
    • CancelButton
    • OkButton
  • Content ("Are you sure?")

Remember, however, that encapsulation lets us avoid having to consider the complete tree when developing.

Container

Looking again at our example, notice how the nesting of the ConfirmDialog and Content objects defines where those objects appear in the user interface:

components: [
  {kind: "ConfirmDialog", components: [
      {content: "Are you sure?"}
  ]}
]

From the application perspective, this nesting describes what we call containment. Specifically, the container of ConfirmDialog is Application, and the container of Content is ConfirmDialog.

To reiterate, Enyo is designed so that developers generally won't need to think about containment--you simply nest the controls as you want them to appear. The concept of containment only becomes important when you want to dynamically rearrange objects at runtime, or create your own sophisticated controls.

To the Application, the containment arrangement looks like this:

• Application
  • ConfirmDialog
    • Content ("Are you sure?")

As usual, the details of ConfirmDialog are hidden from Application.

From the ConfirmDialog's point of view, the containment arrangement looks like this:

• ConfirmDialog
  • ClientArea
  • Content ("Are you sure?")
  • BottomBar
    • CancelButton
    • OkButton

Here is the complete containment tree from the framework's perspective:

• Application
  • ConfirmDialog
    • ClientArea
    • Content ("Are you sure?")
    • BottomBar
      • CancelButton
      • OkButton

(Again, we've shown the full trees here in order to illustrate the underlying concepts, but keep in mind that you'll rarely have to consider these relationships when writing code.)

Returning to the Application object's ownership tree for a moment, notice that the view doesn't specify which object contains the Content:

• Application
  • ConfirmDialog
  • Content ("Are you sure?")

This information is usually not relevant to the logic of the Application, so we are free to rearrange the layout of the user interface without disturbing the logic underneath.

Parent

At this point, users familiar with DOM or other layout systems might ask, "Why use the term 'container' instead of 'parent'?" The reason is to hide another layer of complexity from the developer. We do have a concept of parent, but it's treated as a detail hidden by encapsulation. Often we refer to an object's container as its logical parent. We use the term "container" because the container may be responsible for tracking states or other features of objects, whereas a "parent" only defines the placement of an object in the display geometry.

In our example, the Content object is owned by Application and contained by ConfirmDialog, but its parent is ClientArea. ConfirmDialog may use the parent property to place Content wherever it needs to, without bothering Application about it. All the Application knows is that Content is contained by ConfirmDialog and that ConfirmDialog will select an appropriate parent.

The parenthood tree for the Application is shown below. This is close to what you will see if you inspect the DOM of a framework application:

• Application
  • ConfirmDialog
    • ClientArea
      • Content ("Are you sure?")
    • BottomBar
      • CancelButton
      • OkButton

Other Examples

Chrome

Special blocks called "chrome" define framing or decoration components. Here's the definition of a simple chrome component:

chrome: [
  {kind: "PageHeader", name: "header", layoutKind: "", components: [
      {name: "description", style: "font-size: 14px"}
      {name: "client"},
  ]}
]

Chrome components may also be created using the createChrome method, like so:

this.$.header.createChrome([{name: "moreInfo"}]);

In each case, the new chrome component is both owned and contained by this.$.header.

TabBar

Finally, imagine a TabBar object containing a number of Tab objects. It's up to the user of the TabBar to decide what Tab objects it should have, so the TabBar does not own tabs. However, the TabBar needs to keep track of which tab is selected, so it needs to contain tabs. The TabBar also renders its own background material and has UI to control scrolling and other features. This means that the actual parent of a Tab is probably some control inside the scrolling system, not the TabBar itself.This kind of scenario is why we have the three separate concepts of owner, container, and parent.

Further Reading

Additional discussion of component ownership and containment can be found in More on Ownership and Containment.