Display hierarchy

[Tyler Wright]

Hey Ben -

discussion: I'm considering the best approach for the Display elements defined in Reflex.

context: One of the intents of Reflex is to ride close to the native display list in Flash. This means partly that we don't want a large hierarchy of extension, we want to easily count generations from Component to DisplayObject. But more importantly we want Reflex to integrate well with non-reflex display, where a Reflex component could be dropped onto a timeline in Flash or a Papervision sprite could be added as a child (or skin) to a Reflex component.

Following was my first draft consideration:

Component: provides Behaviors and Skins

extends

Container: provides Children and Layout

extends

ReflexDisplay: provides Width/Height and Measurement

extends

Sprite

I realized though that component extends ReflexDisplay and so want to discuss what the breakout of our displays should be and why. Two of the possible approaches are:

(note: arbitrary children below is in reference to children added from outside of the component/skin definition, as in <Container><Button></Container>) 

1) Component's may not have arbitrary children, their display is entirely defined by their skin. Containers are defined to have and layout arbitrary children.

2) Component's may have arbitrary children, while the component's skin should handle the children's default place of residence. For example, a skinPart named "childrenArea" would automatically contain component's children.

Point #1 is simpler, and I appreciate simple. One of my goals is to keeps things simple and so to justify any complexities. Point #2 has some nice possibilities, but it also means you need to understand more about is happening.

possibility of #2, reaching in and customizing the children of a default skin:

(button skin)

<ButtonSkin>

    <Rect id="highlight"/>

    <Container id="childrenArea">

        <Label id="defaultChild"/>

    </Container>

    <Rect id="background"/>

</Button>

(button placement)

<MyApp>

    <Button>

        <Icon/>

        <Label/>

    </Button>

</MyApp>

I really like this workflow but I'm also concerned for simplicity if this will confuse regular Flash devs. One of the things I hope to get away from is overriding Flash behaviors to do unexpected things, but in this case children are defined through a children:Array, when you getChildAt(i) it's still the real child of the DisplayObject (ie the skinParts).

Thoughts? Comments? Considerations?

Tyler

[Ben Stucki]

Hey Ty,

Yeah, I broke up the original inheritance of Container so that Component extends ReflexDisplay directly. I definitely don't want to kill the idea of having components that can be assigned children directly, as long as the container/layout logic really exists in the skin (as you've shown). Certainly there may be a skinnable container of some kind with a handy box model, etc. What I did want to avoid though is requiring every component to be a container. If people just need simple Slider or TextInput components, I didn't want the unused references to be hanging around. I feel like it's something we can play with in the components library for now and see what works... ?

Also, maybe we should consider changing the name of our "children" property to avoid confusion with addChild, removeChild, etc (which we all agree should not be messed with). Maybe something like "elements" or "items" would better differentiate that these are part of the Reflex "DOM"?

- Ben