On Nov 11, 2005, at 9:42 PM, Scott Evans wrote:
I know that Laszlo Studios rewrites slow code to avoid the constraint
mechanism. Instead of writing <view id="foo" x="${parent.something}"
y="${parent.something}">, they'll write the code that changes
parent.something to update foo's x and y instead, replacing several
function calls and loops through the constraint system by one
function
call. I don't know whether Laszlo Mail uses this optimization, or
uses
it much.
Yah, we did that too -- there are some pieces of the app with a lot of
views that were originally constrained like crazy. It made
operations,
like resizing the contact panel, pretty stuttery. Rethinking all
those
constraints to minimize them and do some programatically by hand
really
helped.
Constraints are so incredibly tasty for rapid prototyping, though.
The $once technique should help, though:
<view name="nugget" width="$once{thingy.width}" ... />
instead of
<view name="nugget" width="${thingy.width}" ... />
My understanding is that this constraint is just evaluated once, when
the view's attributes are first set. This will only work for static
layouts, of course, and only if instantiation order works right. In
this case, thingy must be constructed, and its width attribute must
be set, and "thingy" must be in scope, in order for the $once form to
work.
The other technique that Scott describes is imho more readable (and I
hope, faster, though that is yet to be revealed) than constraints.
The example below positions dotty to sit inside nugget with a padding
of 5 pixels on the left and right.
<view name="nugget">
<view name="dotty" .... />
<method name="init">
this.update();
super.init();
....
</method>
<method name="update">
this.setAttribute("width", thingy.width);
this.dotty.setX( 5 );
this.dotty.setAttribute( thingy.width - 10 );
...
</method>
<!-- Update positioning whenever thingy's width changes -->
<method event="onwidth" target="thingy">
this.update();
</method>
....
</view>
Compare to:
<view name="nugget" width="${thingy.width}">
<view name="dotty" x="5" width="${thingy.width - 10}">
...
</view>
...
</view>
The second form is much more compact and readable, but the first form
uses zero constraints. Arguably, <method event="onwidth"
target="thingy"> is nearly a constraint on thingy.width, but: in the
explicit-update form, one thingy.onwidth event can trigger a single
call to update which, which will end up doing the repositioning that
otherwise would require at least a handful of constraints. Method
calls are expensive. So, fewer constraints, fewer method calls,
faster performance. Maybe -- I haven't done a head-to-head
performance test yet.
-ben shine
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
