Thanks Greg, If the general description for each component in the API documentation states how it expects child components to be added it will certainly make things easier to work with :-)
On Wed, 19 Aug 2009 09:54:42 am Greg Brown wrote: > 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.
