[Laszlo-user] [Laszlo-dev] How should states _really_ work?

[David Temkin]

The docs say:

> Everything within a <state> tag acts as if it were written inside  
> the parent when the state is applied. States can contain attributes,  
> methods, and other nodes.


This is a clean conceptual model, IMHO. No exceptions.

I would expect elements within the state to be added/removed when the  
state is applied/removed. I would not expect elements that are not  
specified within in the state (e.g., other attributes, other methods,  
other views) to be affected by apply/remove of the state. (That's what  
enables what Sarah calls "side effects" below).

I *am* surprised that methods added when a state is applied aren't  
removed when the state is removed -- if that is in fact what Sarah is  
saying below. That sounds like a bug.

Regarding the proximate issue mentioned by Tucker: Sounds like a bug  
in the SWF debugger, and not a general problem with dragstate.





On Feb 21, 2008, at 7:21 AM, Sarah Allen wrote:

> Interesting question! cc'ing Laszlo-user list, since LZX coders on  
> there might have some thoughts on this, or at least be interested in  
> the details of how states  work and whether that should be changed  
> in the future.  I did a little experimentation (see below) to remind  
> myself how states work, and recall a little history of how we got to  
> where we are.  I do like the current behavior (the convenience of  
> implementing dragstate and friends), but I do admit that some of the  
> nuances of states can be confusing and I don't know if they are  
> clearly documented.
>
> The question is: should contraints that are overridden when a state  
> is applies be "put back" when a state is removed?
>
> Conceptually when you apply a state, a bunch of stuff is added, and  
> when you remove it that stuff is removed; however, states are  
> allowed to have side effects, when attributes are modified by a  
> state they stay modified.  So, attributes and methods when applied  
> remain as side effects; however, views and events are temporal and  
> get removed.  Way back in LPS v1, Adam Wolff and I decided that  
> constraints are conceptually like attribute values, even if their  
> implementation is more like an event; which is why we have the  
> behavior we do today.
>
> In an abstract sense, it feels like a bug that when a state is  
> removed, you don't just put everything back the way it was.  If you  
> look at this simple example, that might be your expectation:
> <canvas>
> <checkbox id="cbox"  text="Show"
>           x="10" y="10" />
> <state apply="${cbox.value}">
>    <view bgcolor="blue" x="5" y="30"
>         width="150" height="150" />
> </state>
> </canvas>
>
> However, it is a powerful feature of states that you are allowed to  
> leave a side-effect behind (which is really what enables the  
> simplicity of dragstate and related coding patterns.)  If you change  
> the value of an attribute, it stays that way.  In the following  
> example, after clicking on the checkbox twice to turn it on and off  
> again, the value of the attribute "t" is 10, not it's original value  
> "4"
>
> <canvas>
> <simplelayout/>
> <attribute name="t" value="4"/>
> <text text="${canvas.t}"/>
> <checkbox id="cbox"  text="Show"
>           x="10" y="10" />
> <state apply="${cbox.value}">
>    <attribute name="t" value="10"/>
>    <view bgcolor="blue" x="5" y="30"
>         width="150" height="150" />
> </state>
> </canvas>
>
> Now, I wonder what happens with a method.  In the example below, you  
> will see that if I toggle the checkbox on and back off, the state's  
> method remains, just like an attribute.
>
> <canvas debug="true">
> <simplelayout/>
> <attribute name="t" value="4"/>
> <text text="${canvas.t}"/>
> <checkbox id="cbox"  text="Show"
>           x="10" y="10" />
> <state apply="${cbox.value}">
>    <attribute name="t" value="10"/>
>    <view bgcolor="blue" x="5" y="30"
>         width="150" height="150" />
>      <method name="doSomething">
>         Debug.write('new');
>     </method>
> </state>
>
> <button onclick="canvas.doSomething()">doSomething</button>
> <method name="doSomething">
>   Debug.write('orginal');
> </method>
> </canvas>
>
> Events, get added and removed like views.  In the example below, you  
> end up with two events when the state is applied, then just the  
> original event when the state is removed.
>
> <canvas debug="true">
> <simplelayout/>
> <attribute name="t" value="4"/>
> <text text="${canvas.t}"/>
> <checkbox id="cbox"  text="Show"
>           x="10" y="10" />
> <state apply="${cbox.value}">
>    <attribute name="t" value="10"/>
>    <view bgcolor="blue" x="5" y="30"
>         width="150" height="150" />
>      <handler name="onmousedown" reference="LzGlobalMouse">
>         Debug.write('new');
>     </handler>
> </state>
>
> <button onclick="canvas.doSomething()">doSomething</button>
> <handler name="onmousedown" reference="LzGlobalMouse">
>         Debug.write('original');
> </handler>
> </canvas>
>
>
> P T Withington wrote:
>> As part of fixing LPP-631 in r8032, states now remove constraints  
>> that they override when applied, and they _restore_ those  
>> constraints when removed.  This breaks dragging and resizing of the  
>> swf debugger window!
>>
>> The swf debugger starts out with its dimensions defaulted to a  
>> percentage of the canvas.  Percentage values are constraints.  This  
>> is nifty, because if you resize your browser window, the debugger  
>> window nicely resizes too.
>>
>> But if you try to drag or resize the window, the drag or resize  
>> state gets applied, the window tracks the mouse, but when you let  
>> go of the mouse, the state gets removed and the previous percentage  
>> constraints are reinstalled, snapping the window back to its  
>> starting position.
>>
>> My question:  Is this a bug in states?  Should they _not_ restore  
>> constraints they removed?  Is this a bug in drag/resize states?   
>> Should they be overriding the base state behavior of restoring  
>> constraints?  Or, is this just a bug in the swf debugger?  Should  
>> it only size to the canvas initially and not respond to canvas  
>> changes?  Or should it be improved to track the canvas until it is  
>> resized or dragged?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-user/attachments/20080221/14f787c0/attachment.html