On Tue, Jul 16, 2013 at 11:33 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> >>
> >> Removed initModel and initSkin methods. The lifecycle is now much
> >simpler: instantiate, set properties and beads then add to the display
> >list. We're still using child.addToParent(parent), but I am going to
> >experiment next with changing over to parent.addElement(child).
> >
> >Any particular reason why? I was beginning to get a hang of the
> >child.addToParent() way.
>
> The short answer: to reduce migration pain. My internal customer showed
> me a bunch of code with a lot of addElement() calls in it.
>
There seemed to be a reason you but I don't remember it either. :) Reducing
migration pain is good.
>
> The long answer: I was looking at how addToParent() is currently
> implemented and found that I couldn't completely remember why I felt it
> was a better strategy. Current Flex has tried two approaches so far, the
> main issue being: how do you manage children in a container? The two
> approaches:
>
> 1) addChild + rawChildren.addChild
> 2) addElement goes to contentGroup (and block addChild)
>
> The choice for FlexJS is mainly about how to do it on the JS side. We
> could use one of these two strategies, or use addToParent() or even go
> with the HTML/JS appendChild/insertChild, or something else. I'm actually
> quite undecided at this point, which is why I hope the experiment will
> help finalize the decision.
>
> So far, I've had the following thoughts:
>
> A) wrapping addChild messed up a lot of low-level tools like display list
> tree walkers used in Spy-like programs. I'm leaning against wrapping
> addChild again.
>
What happened?
> B) addToParent requires that the child have some knowledge about the
> parent. Maybe it is better for the parent to have some knowledge about
> the child.
>
> C) addToParent worked well for simple control composition, but when I
> ended up having to abstract out the actual parent when managing container
> children on the AS side I ended up with an "internal" addChild contract
> anyway.
>
But in my opinion the control should be concerned with itself. It should be
concerned with how it behaves and how it appears visually at different
sizes. It's layout, depth and relation to container and other controls
should be a concern of the parent container IMHO. For example, you have
graphic elements like rect and circle. Their only job should be to draw
their visuals. On the other lazier hand you could save time by NOT
requiring every visual element implement an addToParent / removeFromParent
like methods and interface.
One method I've seen is the layout and position reside outside the control
(maybe you are doing this already). For example, there is a specific object
that contains the layout properties:
<LayoutObject target="{container1}" top="10" right="50" width="100%"
height="100%"/>
<BasicContainer id="container1" >
<LayoutObject left="10" top="50" width="220" height="25">
<Button id="button1" label="Hello World"/>
</LayoutObject>
<AdvancedLayoutObject target="button2" left="button1:10"
top="button1:50" width="220" height="25"/>
<Button id="button2" label="Hello World"/>
<HorizontalLayoutObject left="10" top="250" width="220" height="25"
gap="10">
<Button id="button3" label="Hello World"/>
<Button id="button4" label="Hello World"/>
<Button id="button5" label="Hello World"/>
</HorizontalLayoutObject>
</BasicContainer>
I'm not sure where I'm going with this... except that I've seen this and
there may be a situation where the controls are never "added" to the object
that lays them out. This could be the case with canvas or absolutely
positioned nested elements.
