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

[P T Withington]

On 2008-03-21, at 18:19 EDT, André Bargull wrote:
>> When the state is removed, the attribute retains the final value  
>> that it had when the state was still applied.
> So, the example from "http://www.openlaszlo.org/lps4/docs/developers/constraints.html#d0e66645 
> " won't work anymore in favor of LPP-631?
> I'd expect if a constraint was removed when a state got applied,  
> that the same constraint will be re-installed after the state has  
> been removed. Basically just disabling/re-enabling the delegates for  
> that constraint.

But we know when we tried that lots of things broke.  For instance,  
the swf debug window, which sizes itself to the canvas by default, but  
expects that when you drag it that constraint will be removed and the  
window will follow the dragger and when the dragger is released it  
stays where it was left, it does not resize itself to the canvas again.

What am I missing?  How can we have it both ways?

>> It is an error to specify an attribute in a state that _is_not_  
>> already declared in the parent.
> But states rely on having helper-methods *and* helper-attributes,  
> for instance dragstate, there you've got "__dragstate_getnewpos" as  
> a helper-method and "__dragstate_xdoffset" as a helper-attribute.  
> Both are needed!

We can probably allow you to add attributes.

On 3/21/2008 10:03 PM, P T Withington wrote:
>> I think we are converging on:
>>
>> 1) A state's primary purpose is to change the value of an attribute  
>> in its parent.  Typically this means the state re-declares the  
>> attribute with a different initial value (which may be a constant  
>> or a constraint).  When the state is applied, the attribute takes  
>> on the value specified by the state (which means removing any  
>> constraint specified in the parent).  When the state is removed,  
>> the attribute retains the final value that it had when the state  
>> was still applied.  It is an error to specify an attribute in a  
>> state that _is_not_ already declared in the parent.
>>
>> 2) A state may need to specify some 'common subroutines' to support  
>> its constraints.  These are written as methods in the state.  The  
>> methods of a state will be methods of the parent of the state, but  
>> they may not use `super` calls.  In this sense, they are simply  
>> common subroutine functions attached to the parent so that they can  
>> be invoked as `this.<name>`.  It is an error to specify a method in  
>> a state that _is_ already defined in the parent.
>>
>> In summary:  A state can change the values of an attribute in its  
>> parent and it can specify methods to be added to the parent in  
>> support of computing the changed values.
>>
>> In the above description, 'parent' refers to the dynamic parent of  
>> the state.  That is, a state is subject to placement and affects  
>> the view that it is placed within, not the view it is declared  
>> within.
>>
>> ---
>>
>> There was lots of theory bandied about regarding what states might  
>> do in the abstract, but after surveying their current usage we  
>> believe the above definition is sufficient to support that usage  
>> and still tractable for compiling to JS2 runtimes.
>>
>> On 2008-03-21, at 10:33 EDT, André Bargull wrote:
>>> Any news for this issue? It is still marked as 'unresolved' in my  
>>> local inbox..
>>>
>>>
>>> On 2/23/2008 9:36 PM, P T Withington wrote:
>>>> André points out that this example:
>>>>
>>>> http://www.openlaszlo.org/lps4/docs/developers/constraints.html#d0e66645
>>>>
>>>> Will not work, with my fix to LPP-631, because to fix that, I  
>>>> made states _remove_ the parent constraint when the state sets  
>>>> the the same attribute, so, once you drag one of the boxes, it  
>>>> will no longer track the other view.
>>>>
>>>> We can't have it both ways.  Is http://jira.openlaszlo.org/jira/browse/LPP-631 
>>>>  not a bug after all?
>>>>
>>>>
>>
>>