On 2008-02-21, at 13:37 EST, 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.
Event handlers are cumulative (they are anonymous), so as I said in my
gory details, you don't have the ambiguity of attributes and methods.
Handlers in the state get added when the state is applied and removed
when the state is removed. Handlers in the parent just stay as they
are.
We should be explicit about which elements of the <state> are
applied, and which are removed or restored.
Indeed. It would simplify our life if methods were not one of those
elements.
"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?
I mean that the only thing about an attribute that is duplicated in
the parent and the state that you can change is its value. You can't
change its type, give it a new setter, or any other properties that I
might not have thought about. This is a specification-writer's trick
to close the barn door before the horse gets out, as opposed to our
current design philosophy of "someone once tried this crazy hack which
makes no sense but it is now the de facto API so we have to support it
forever".
- 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!
