Hi Carlos,
On 7/16/13 12:49 PM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote:
>Hi Alex,
>
>The short answer: to reduce migration pain. My internal customer showed
>> me a bunch of code with a lot of addElement() calls in it.
>>
>>
>I thought migration was not considered in FlexJS. IMHO, I think that
>should
>not be considered in the discussion of add to child vs add to parent.
Migration is still an important factor, but backward compatibility isn't
being guaranteed. What that means to me is that I'm not promising that
every API in current Flex will be there in FlexJS, and we are going to try
to find the best API for the future, but if given a choice of similar
options, I would choose the old API names as that will reduce the amount
of editing of existing source in your applications. The more lines you
have to change, the more you will consider other options like a full
rewrite to some other framework.
>
>
>
>
>> 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.
>>
>
>When you proposed the change to addToParent I thought it was a great
>change.
>I think one of the reasons was that actual mxml compilation to AS3 was
>producing a less
>performant way to build the displaylist tree and add to parent or bottom
>up
>direction could be
>better and more simple solution.
That's interesting. Can you describe your scenario in more detail? In my
experience folks creating display object trees in AS3 were doing it less
efficiently than MXML. Top-down has been faster than bottom-up in my
measurements, mainly because being assigned a parent is the last good
place to run initialization code without an additional API call so styles
get fixed up in addChild/addToParent. IOW,
var button = new Button();
var container = new Container();
container.addElement(button);
application.addElement(container);
is not as efficient as:
var container = new Container();
application.addElement(container);
var button = new Button();
container.addElement(button);
because the Button's inheriting styles have to be recalculated at each
addElement() in the first case.
And what I'm talking about here is that if you had code that looked like
the second case, and there are no other benefits, maybe we shouldn't make
folks re-write it like this:
var container = new Container();
container.addToParent(application);
var button = new Button();
button.addToParent(container);
And note that you can use addToParent to create trees bottom-up as well as
top-down.
>
>
>
>
>>
>> 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.
>> 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.
>>
>
>Why the child needs to know something about the parent beside some
>interface or inheritance knowledge?
>In my mind both methods seems to require the same knowledge...
I agree, but there's a subtle difference that is bugging me. See below:
>
>
>
>> 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.
>>
>
>could you elabore a bit more about this?
Sure. Originally, addToParent() looked like this:
public function addToParent(p:Object):void
{
p.addChild(this);
}
Then I had to change it to look like this:
public function addToParent(p:Object):void
{
if (p is UIBase)
UIBase(p).internalAddChild(this);
else
p.addChild(this);
}
The internalAddChild provides the abstraction for what the parent wants to
actually do with the child. This was necessary for Containers. But the
code is using UIBase not IUIBase, and when I changed to IUIBase I got
other errors because simple controls like Button or Label don't have
children and thus shouldn't have to implement internalAddChild. I could
add another interface for containers, but it bugs me that complex
composited controls have to implement a "container" interface.
So the proposed change in UIBase.as is this (I have to add a
getActualChild to IUIBase as part of this change):
public function addElement(child:Object):void
{
if (child is IUIBase)
addChild(IUIBase(child).getActualChild());
else
addChild(child);
}
It is pretty much the direct opposite, but it feels better to have the
parenting logic in the parent than in the child.
>
>
>>
>> Opinions and contributions always welcome,
>>
>
>One of the changes that make FlexJS a great promise is this addToParent
>change...maybe now that you has more experience find that it's not as good
>as it might seem, but since it was one of the great promises of the new
>framework I'd like to discuss and help to find the main points for and
>against to help take the decision.
Thanks for helping me think it through.
-Alex
