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

[Sarah Allen]

"attributes that were set by the application of the state are not 
restored."  -- these are the side effects I was referring to.  The 
constraint that was applied was removed, but the value of the attribute 
set by the constraint is not. 

If you think that it is a bad idea for states to have these side 
effects, how would dragstate and resizestate work?

Sarah

David Temkin wrote:
> The docs now say:
>
>> When a state is removed, any children or constraints created when the 
>> state was applied are then removed, but attributes that were set by 
>> the application of the state are not restored.
>
> It sounds like this isn't quite right. Are event handlers also 
> restored to their previous value when the state is removed? And then 
> it says that constraints are removed, which does not seem to be 
> consistent with current behavior. If "children" means "child views" 
> then methods are excluded.
>
> We should be explicit about which elements of the <state> are applied, 
> and which are removed or restored. 
>
> "Side effects" -- other attributes that have been changed by running 
> application code, in the view that contains the state, or elsewhere -- 
> are not part of the picture. 
>
> I am unclear on what this means specifically: "It is an error for the 
> state to specify any other properties of the attribute that would 
> conflict with the parent." Tucker? 
>
> - D.
>
>
>
>
> On Feb 21, 2008, at 9:54 AM, P T Withington wrote:
>
>> Executive summary:  I propose amending the documentation as follows:
>>
>> "When a state contains an attribute with the same name as in the 
>> parent node, the attribute will take on the value specified in the 
>> state when the state is applied.  It is an error for the state to 
>> specify any other properties of the attribute that would conflict 
>> with the parent.  When the state is removed, the value of the 
>> attribute will remain the value at the time the state is removed."
>>
>> ---
>>
>> Gory details: if the parent value was a constraint, it will be 
>> removed when the state is applied and replaced with the state value. 
>>  If the state value is a constraint, it will be removed when the 
>> state is removed.
>>
>> If we need to support this feature for _method_ attributes going 
>> forward, we'll have some work to do.  Does anyone feel this is necessary?
>>
>> Note that (for better or worse) _handler_ attributes do not collide 
>> in this way, since it is perfectly legal to have many handlers with 
>> the same `name` -- the name in a handler attribute is the event that 
>> it handles, not the name of the handler.
>>
>> More comments interspersed below...
>>
>> On 2008-02-21, at 11:16 EST, 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.
>>
>> The docs are silent on what happens when the state is removed?
>>
>>> 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).
>>
>> The question at hand is:  what if the parent _and_ the state specify 
>> the same element?  If you take your doc quote literally, this would 
>> be an error.  You are not allowed to declare the same attribute 
>> twice.  But everyone relies on this being permitted, usually to apply 
>> a constraint to an attribute with a state.
>>
>> The bug I just fixed was if you had a constraint in the parent and 
>> applied a fixed value in the state.  The state has to remove the 
>> parent constraint when applied or you don't get what you want.
>>
>> I thought it would also be more correct to put those removed 
>> constraints back when the state is removed, but that breaks dragstate 
>> and resizestate (not just in the debugger -- Amazon broke too.  There 
>> are probably others.  So I am taking the re-applying of removed 
>> constraints back out).
>>
>>> 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.
>>
>> Her example is another case of the attribute (in this case a method 
>> attribute) being defined in both the parent and the state.  When the 
>> state is applied, the method attribute gets a new 'value' (the method 
>> implementation), and when the state is removed, that new value 
>> sticks.  You don't get two methods with the same name.  If the method 
>> had a different name than any parent method, it would be added and 
>> removed.  But ans Henry points out, adding and removing methods is 
>> problematic for JS2 runtimes.
>>
>>> Regarding the proximate issue mentioned by Tucker: Sounds like a bug 
>>> in the SWF debugger, and not a general problem with dragstate.
>>
>> Nope.  Many things break if I restore constraints that were removed 
>> by the state.
>>
>> The comment on LzState#remove says:
>>
>>> /**
>>>  * Removes the constraints and views made when the state was 
>>> applied. This
>>>  * method does not currently restore the previous values of any 
>>> attributes that
>>>  * were changed by the state
>>>  */
>>
>> 'does not currently' made me think that was a shortcoming, but it 
>> appears it is a feature instead!
>>
>