[Laszlo-dev] About moving nodes...

[Johannes Boesl]

In my application I did some kind of component-caching. Components in 
laszlo need quite some time to be initialized. I remember simple buttons 
took up to 50 ms in my testings so I came up with the idea of keeping 
the components and reusing it.
I was able to solve issues with clipping and so on but it wasn't an easy 
task. If it had been possible to reparent views it would have been 
easier to accomplish.



P T Withington schrieb:
> 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
>>
>