[Laszlo-dev] About moving nodes...

[Raju Bitter]

I remember that this is a limitation of an the SWF runtime until AS2/ 
SWF8. Starting with AS3/SWF9 the behavior of managing visible objects  
was modified:

http://my.safaribooksonline.com/0596526954/ID-d2450e71-Introduction529380
> Anytime a MovieClip was created (in AS2), it was automatically added  
> into the visual hierarchy and consequently drawn by the renderer.  
> MovieClips weren't able to move to different places within the  
> hierarchy; instead, they first had to be destroyed and then  
> recreated before they could be positioned elsewhere in the display.
>
> The new renderer (AS3/SWF9) is still hierarchical, but not as rigid,  
> and aims to simplify and optimize the rendering process. The new  
> rendering model centers on the display list concept and focuses on  
> the classes available in the flash.display package. The display list  
> is a hierarchy that contains all visible objects in the .swf movie.  
> Any object not on the display list is not drawn by the renderer.

That means, you can remove the object from a display list and add it  
to a new display list. Here's a code example:
<canvas width="100%" height="800">

   <view id="containerA" y="100" width="200" height="200"  
bgcolor="blue">
     <view id="targetObj" width="150" height="150" bgcolor="yellow">
       <method name="whereAmI">
         Debug.write("Parent for targetObj view: " + this.parent);
         var s = this.getDisplayObject();
         Debug.write(s);
         Debug.write("Owner for targetObj view: ", s.parent.owner);
       </method>
       <button text="Click me!" onclick="parent.whereAmI()" />
     </view>
   </view>

   <view id="containerB" x="400" y="100" width="200" height="200"  
bgcolor="green">

   </view>

   <button text="move yellow view" onclick="moveView()">
     <method name="moveView">
       if ($as3) {
         #passthrough {
         Debug.write(containerA.getDisplayObject());
         var spriteA = containerA.getDisplayObject();
         spriteA.removeChild(targetObj.getDisplayObject());
         var spriteB = containerB.getDisplayObject();
         spriteB.addChild(targetObj.getDisplayObject());
         }#
       } else if ($as2) {
         Debug.warn("Moving display objects from one movieclip to  
another not supported in AS3");
       }
     </method>
   </button>

</canvas>

Run this in SWF: you can move the yellow view from the blue to the  
green box. #containerA is still listed as parent, even if the yellow  
view has been attached to #containerB, but the owner reference changes.

@Henry: Do you have any idea what impact such an action of would have  
on the OL view system?

- Raju

On Oct 17, 2009, at 7:18 PM, P T Withington wrote:

> There is a `placement` attribute, and a `determinePlacement` method  
> that can be overridden by a class, but both of these expect the  
> final placement of a node to be determined at construct time.  I  
> don't know if this restriction is inherent to LzNode, or was a  
> restriction due to some ancient runtime (e.g., swf5).  It might be  
> possible to make placement dynamic.  Clearly any parent/child  
> dependencies would have to be tracked and adjusted as part of this.
>
> <state> is sort of a half-step to this, in that it can dynamically  
> remove and add child views, but state does _not_ guarantee the child  
> view's state information is preserved.  In effect a state destroys  
> and re-creates the child views it controls each time.
>
> You can modulate the `visible` attribute of a view to hide/reveal it  
> and all its children.  Modulating the visibility _does_ preserve the  
> hidden views state.
>
> I'd be interested in seeing an example of an application where views  
> need to move.
>
> On 2009-10-16, at 20:39, Rami Ojares / AMG Oy wrote:
>
>> Hi,
>>
>> Would it even be theoretically possible to make parent attribute of  
>> node read/write.
>> Now moving nodes around means destroying old ones and creating new  
>> ones under new parent.
>> This becomes a nightmare when the nodes have all kinds of  
>> connections to other nodes.
>>
>> I know this is a BIG issue but I wondered if this would be even  
>> theoretically possible and what it would require.
>>
>> Now that I do it manually I will have to maintain two way links  
>> between dependencies.
>>
>> Example:
>> - A depends on B (a is listening to events from B)
>>
>> If I move B I have to know who is listening so I can update the  
>> delegates to listen to events from the new B node
>> If I could move B without destroying it and creating a new one, the  
>> delegates would not need updating.
>>
>> - rami
>>
>