On Thu, Feb 21, 2008 at 1:37 PM, David Temkin <[EMAIL PROTECTED]> 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. > There can be as many event handlers as you want registered to a given event, so the state can unregister just the ones that it registered. They are "linearly additive" with each other, to use a physics analogy. > 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? > For example, if you declared an attribute as a number type, then you can't have the state declare it as a string type. Or if you have declared a setter for an attribute in the main view, the state shouldn;'t declare a different setter for it. > - D. > > > >
