I think it's about 50/50 between calling lzstate.apply() explicitly , and calling it implicitly via a constriant, based on the usage I see in the components library and demos, and production app code.
On Thu, May 15, 2008 at 11:25 AM, David Temkin <[EMAIL PROTECTED]> wrote: > Sounds good, but the method "apply" sticks around, right? That, I think, is > and will be the more typical way of controlling a state. > > On May 14, 2008, at 4:54 PM, Henry Minsky wrote: > > I endorse this proposal. > > > > > On Wed, May 14, 2008 at 7:23 PM, P T Withington <[EMAIL PROTECTED]> wrote: > >> We need to clean up the API for states. Right now states have both an >> attribute _and_ a method named `apply`. This just makes no sense. It is >> implemented by a horrendous kludge that we will not be able to carry forward >> into Javascript 2 runtimes. Here's my proposal: >> >> 1) Deprecate `apply` the attribute. Replace it with `applied`, which is a >> read/write attribute whose value reflects whether or not the state is >> currently applied. (There is currently a property `isapplied` that is >> read-only that tells the state of a state, but this name is inconsistent >> with our name conventions. As a part of this proposal, deprecate >> `isapplied` and replace it with `applied`. >> >> The `apply` method (and it's counterpart `remove`) remain, but the >> preferred method for controlling a state is to constrain the `applied` >> property. >> >> We can add to the 4.x upgrade script a template that looks for `apply` in >> the open tag of a state and replaces it with `applied`. >> >> Comments? >> > > > > -- > Henry Minsky > Software Architect > [EMAIL PROTECTED] > > > -- Henry Minsky Software Architect [EMAIL PROTECTED]
