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

Thu Feb 21 10:02:40 PST 2008

Wouldn't this work on a dynamic class as opposed to a sealed class?

Not good if this can't be made to work at all.

On Feb 21, 2008, at 8:45 AM, Henry Minsky wrote:

> Going forward, we cannot really be messing with methods in the same  
> dynamic way we have been up to this point,
> because we're not free to define or delete them at runtime in swf9,  
> nor many other runtimes we might want to
> target.
>
> We should assume that methods are things that only can be defined at  
> compile time, and cannot be deleted.
> If you define a method inside a state, that will have to be  
> equivalent to defining it outside of the state.
>
> I suppose if we were masochistic we could make the compiler merge  
> methods at compile time with some kind
> of dispatch flag to say which method body code to run depending on  
> if a state is applied, but that doesn't
> seem maintainable  to me.
>
>
>
>
>
>
> On Thu, Feb 21, 2008 at 11:16 AM, David Temkin <temkin at laszlosystems.com 
> > 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?
>>
>
>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>

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