[Laszlo-dev] [Laszlo-user] How should states _really_ work?

[Bret Simister]

What was the purpose for creating the mechanism of states? States solved 
a need that was not being addressed simply with layouts, animators, and 
constraints.

How could we "declaratively"  define the "state" of  a screen, i.e. how 
could we define all of the necessary visual and functional changes that 
would need to happen simultaneously,  and preferably within a single 
line of code. States ( though not necessary)  are an elegant component 
of the cinematic user experience. It allows a programmer to separate the 
"objects" of screen from the relationships between those objects. 
States were meant to be like "tools" that chisel and shape a screen into 
a new visual and functional state by adding ( and removing )  what is 
necessary as well as changing the values and relationships of the 
objects already there.

As Sarah stated...

  " ... however, it is a powerful feature of states that you are allowed 
to leave a side-effect behind (which is really what enables the 
simplicity of dragstate and related coding patterns.)   ....   In an 
abstract sense, it feels like a bug that when a state is removed, you 
don't just put everything back the way it was. "

Yes it is a powerful feature ( to leave the altered values of attributes 
once a state is removed ), but that is not a side effect. THAT IS THE 
PURPOSE of states. Again they are like dynamic tools reshaping the 
screen to a new function and display. If you need to go back to an 
"original" state then just declare that state and invoke it when 
necessary. It does not seem like a bug to me to automatically go back to 
a previous values once another state is removed.  That is why dragging 
works so elegantly with states, as well as a lot of other cool designs 
and visual effects. Again, states should be better documented if this 
seems confusing. The flexibility ( in what is described above ) is much 
more powerful than simply going back to the "original" state once 
another state is removed. Also, if an attribute is originated within a 
state, then I believe that attribute should also be removed once the 
state is removed. That may seem like a contradiction, but attributes 
added ( not just redefined ) within a state are meant to "locally" 
support the new state. If an attribute needs to live across states, then 
it should be defined outside the states as well.

In general, what  should be added and removed when states are added and 
removed... ( here is my opinion in an ideal world )

given the following class...

   <class>
      <attribute name="attrA" value="n" />
      <attribute name="attrB" value="${ ...}" />
      <method name="methodOne"
      <method name="methodTwo"
      <view name="viewA"
      <view name="viewB"
      < state name="mystate" ...  >
	<attribute name="attrA" value="${}" />
	<attribute name="attrC" value="5" />
	<method name="methodB" ../>
	<method name="methodC" .../>
             <view name="viewC" ... />
      </state>
<class>

      when "mystate" is applied...
      	attrA should now be turned into a constraint
      	AttC gets added with a value of 5
      	methodB gets added and overrides the previous methodB
      	methodC gets added
          	viewC is be added [ on top of the other views ]

      when "mystate" is removed...
      	attrA should now be turned back into a value ( using the current 
value ... not back to its original value )
      	AttC is removed completely
      	methodB is removed and replaced with the original methodB
      	methodC is removed
          	viewC is removed

I know that we cannot do this exactly. I do not claim to fully 
understand the challenges involved with dynamically adding and removing 
methods at runtime. Which ever way it can be implemented, it should be 
documented on the exact mechanics of its function. If, in the platform 
implementation,  "methods"  cannot be both added and removed during 
runtime all I can say is ... if a method is present and nobody invokes 
it ... is it really there? Yes, it takes up space, but are there any 
other effects if it is still present but not used? This may not be the 
ideal solution but the code would still function correctly.

Keeping the flexibility of States, outlined above, allows developers to 
implement  Sarah's abstract case ( i.e. going back to original values 
once a state is removed) by using two states. Automatically reseting all 
values once a state is removed would reduce if not eliminate the power 
of States overall.

-Bret

On Thu, Feb 21, 2008 at 11:11 AM, Henry Minsky wrote:


On Thu, Feb 21, 2008 at 1:37 PM, David Temkin < temkin at laszlosystems.com 
<mailto:temkin at laszlosystems.com> > wrote:
The docs now say:  <mailto:temkin at laszlosystems.com>

  <mailto:temkin at laszlosystems.com>
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. 
<mailto:temkin at laszlosystems.com>

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.  <mailto:temkin at laszlosystems.com>

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.

  <mailto:temkin at laszlosystems.com>

  <mailto:temkin at laszlosystems.com>
We should be explicit about which elements of the <state> are applied, 
and which are removed or restored.   <mailto:temkin at laszlosystems.com>

  <mailto:temkin at laszlosystems.com>
"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.   <mailto:temkin at laszlosystems.com>

  <mailto:temkin at laszlosystems.com>
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?   <mailto:temkin at laszlosystems.com>

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.


  <mailto:temkin at laszlosystems.com>

  <mailto:temkin at laszlosystems.com>
- D.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080221/a9486019/attachment.html