Great question. Many containers define a property or set of properties
that clearly express the subcomponents that a caller is allowed to
manipulate. If no such properties are defined, then it is safe to
simply add components directly to the container itself.
Some examples:
- Window, Border, and Expander define a "content" component
- TablePane defines row and column sequences
- ScrollPane defines "view", "rowHeader", "columnHeader", and "corner"
component
- TabPane defines a "tabs" component sequence and a "corner" component
- Accordion defines a "panels" component sequence
- Rollup defines "heading" and "content" components
There are only a handful of containers that *don't* actually fall into
this category. I think it is only FlowPane, BoxPane, and CardPane.
The main reason for this is to allow a container skin to add (and lay
out) other components as necessary to achieve the desired UI (for
example, TerraTabPaneSkin adds tab buttons, TerraAccordionSkin adds
header buttons, etc.). Those components are then never directly
exposed to the caller via the container's API. However, it is also
useful in other cases - for example, TablePane uses its column and row
sequences to establish the structure of its component grid.
So, it's largely a documentation issue. But I can definitely see it
causing some initial confusion.
Hope this helps.
G
On Aug 18, 2009, at 6:58 PM, Scott Lanham wrote:
Hi Guys,
Sometimes there is a content property for a component and sometimes
the child
components are just listed under the definition of the object like
with
BoxPane.
Can you give me some clues please as to when to expect a content
property and
when not to?
Thanks,
Scott.
