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

[André Bargull]

> What am I missing?  How can we have it both ways? 
Yes, I do think so. All these issues like the one with the debugger came 
from that line in LzNode#applyConstraintMethod(..):
> // Whether there are dependencies or not, we need to invoke the
> // constraint function (since the dependencies may have 'fired'
> // before the constraint was installed).
> this[constraintMethodName]();
If you don't execute the constraint-method when you re-enable the 
constraint after removing the state, you won't get any problems. This is 
what I tried to do in this patch 
"http://svn.openlaszlo.org/openlaszlo/patches/20080217-bargull-4.tar".


On 3/22/2008 12:05 AM, P T Withington wrote:
> 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?
>>>>>
>>>>>
>>>
>>>
>
>