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

[André Bargull]

> 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.

> 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!


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?
>>>
>>>
>
>