[Laszlo-dev] How should states _really_ work?

[Sarah Allen]

Those docs don't make it clear what happens when there is a collision, 
and then what happens when the state is removed.  Under discussion is 
the behavior when an attribute is defined in the state AND in the parent 
of the state -- in this case, states currently may have a "side effect," 
as I discussed in my note. If states never had side effects, when you 
removed a dragstate then the window or whatever would zap immediately 
back to where it came from.  The application of a state should never 
affect anything that is not defined within the state.

Sarah

David Temkin wrote:
> 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-dev/attachments/20080221/3b083e9f/attachment.html