What am I missing? How can we have it both ways?
Yes, I do think so. All these issues like the one with the debugger came
from that line in LzNode#applyConstraintMethod(..):
// Whether there are dependencies or not, we need to invoke the
// constraint function (since the dependencies may have 'fired'
// before the constraint was installed).
this[constraintMethodName]();
If you don't execute the constraint-method when you re-enable the
constraint after removing the state, you won't get any problems. This is
what I tried to do in this patch
"http://svn.openlaszlo.org/openlaszlo/patches/20080217-bargull-4.tar";.
On 3/22/2008 12:05 AM, P T Withington wrote:
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?
