Hi Edgar, That's a very good question about a common source of confusion. Let me attempt to answer in such a way so as to explain not only TablePane, but many other containers... This topic should probably be covered in the "knowledge base", were we to have one :)
Container fundamentally provides us with the component *hierarchy*. Without it, we'd simply have a bunch sibling components, which would be... messy :) As part of providing this hierarchy, it is responsible for things such as propagating mouse events, focus traversal, translating coordinate spaces during paints, etc. A Container knows of its child components via implementing Sequence<Component>. If *and only if* a child component is in this sequence, it will receive propagated mouse events and paint() calls from the container. Now enter the concept of layout. Layout is the process by which components are organized within their parent. It is the responsibility of the parent itself (technically, the parent's skin) to lay out its children (Panel non-withstanding). Each Container subclass defines a different layout policy. That policy may require it to differentiate its children and treat each one differently. Take TablePane, for instance; it needs to know the cell in which to place each child component. If all it had were a sequence of components, it wouldn't know which one went at 0,0, which one at 1,0, etc. These types of containers define other data structures or members to denote these characteristics. TablePane defines getRows() [RowSequence implements Sequence<Component>]. When you add a component to a table pane row, you're also implicitly adding it to the Container's component sequence (that happens behind the scenes), but moreover, you're telling the table pane how to lay out the child component. This design applies to a bunch of containers; Rollup (setHeading(), setContent()), TabPane (setCorner(), getTabs()), Accordion (getPanels()), Window (setContent()), and Border (setContent()) are a few of them. So what would happen if you added a component to a table pane using tablePane.add(component) instead of adding it to a row? You would have successfully added a child component to the table pane, but the table pane's skin wouldn't know how to lay the child out, so the child's size and location would remain untouched. As a test of this, try the following: <Window maximized="true" xmlns:wtkx="http://pivot.apache.org/wtkx"; xmlns="org.apache.pivot.wtk" styles="{backgroundColor:'#777777'}"> <content> <TablePane> <columns> <TablePane.Column width="1*" /> <TablePane.Column width="1*" /> </columns> <rows> <TablePane.Row height="1*"> <Panel styles="{backgroundColor:'#000000'}" /> <Panel styles="{backgroundColor:'#ffffff'}" /> </TablePane.Row> <TablePane.Row height="1*"> <Panel styles="{backgroundColor:'#ff0000'}" /> <Panel styles="{backgroundColor:'#00ff00'}" /> </TablePane.Row> </rows> <Panel styles="{backgroundColor:'#0000ff'}" x="25" y="25" width="50" height="50" /> </TablePane> </content> </Window> In this example, the table pane skin will lay out the black, white, red, and green panels in the four cells, but it won't touch the blue one -- the blue one will remain at 25,25+50x50. If you resize the table pane, the panels in the cells will get resized too, but again, the blue one will remain untouched. So one question you might have is "Why this design? Why not use attributes?" Some other toolkits attach attributes to child components to provide such metadata. In fact, Pivot itself uses attributes that it attaches to child components to provide metadata such as a tab's label within a TabPane. However, Pivot does *not* use attributes to specify layout metadata; mainly to promote code cleanliness. In the case of TablePane, if each child component had a ROW and COLUMN attribute attached to it, then what would happen when you dynamically inserted (or removed) a row or a column from the table pane? You'd have to update your book-keeping of all the attributes to increment or decrement the associated row or column attribute. The same goes for the tab pane tabs, accordion panels, etc. We believe that the "special designation children" design yields a cleaner distinction than you would achieve via attributes. I hope that helps. It was a little long winded, but it was a deep question :). Greg knows this stuff better than I do, so he probably has a good perspective and can add a lot here as well. Cheers, -T On Wed, Sep 23, 2009 at 7:46 PM, Edgar Merino <[email protected]> wrote: > Hello, long time I haven't write to this list. I'm currently developing a > "text engine" for php, most of the component hierarchy model I'm using is > based on pivot (conceptually). For laying out components I've chose to use > Containers too, by looking at TablePane's source code I see it extends > Container, but somehow I don't see it using the "components" ArrayList > Container has, instead it's defining it's own Sequences (RowSequence and > ColumnSequence) and using them, ignoring it's parent's components. So the > question is, what is the reason behind TablePane extending Container? adding > a component to a TablePane using TablePane#add() doesn't make sense to me, > but maybe I'm missing something. > > P.S. I still have some code I'd like to contribute, but work's on me right > now :). > > Thanks in advance, > Edgar Merino >
