[Laszlo-dev] About moving nodes...

[P T Withington]

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
>