Mailing-List: contact pivot-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pivot-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gkbrown@mac.com designates
 17.148.16.86 as permitted sender)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Message-id: <B4FCCB92-37A5-4180-8F87-E41FEA63FBB7@mac.com>
From: Greg Brown <gkbrown@mac.com>
To: pivot-user@incubator.apache.org
In-reply-to: <200908191004.58193.lists@sael.com.au>
Subject: Re: Content Property
Date: Tue, 18 Aug 2009 20:07:54 -0400
References: <200908190858.30397.lists@sael.com.au>
 <8178CA71-EA9D-4068-9225-5A7E8A018EEB@mac.com>
 <200908191004.58193.lists@sael.com.au>

Yeah. Improving documentation is very high on our to-do list. We will  
be focusing on it post-1.3, and trying to really solidify it for 1.3.1.


On Aug 18, 2009, at 8:04 PM, Scott Lanham wrote:

> 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.
>