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?
