Tuesday, September 26, 2006
Saturday, September 23, 2006
OpenLaszlo debugging tips from Tucker
Debug.write("My message, hooray.");
This method is variadic and clever. Comma-separated arguments are printed as "live" debugger objects.<method name="doSomething" args="x">
Debug.write("This is", this, "and x is", x);
</method>
gives you this...This is #theView and x is 27
and the debugger will print (almost) everything it knows about #theView.
lzx> Debug.inspect(#theView)
#theView {
_events: [LzEvent, LzEvent]
_instanceAttrs: «Object#1#3| {id: theView, bgcolor: 2383748, height: 40, width: 40}»
_instanceChildren: «undefined»
addedToParent: true
bgcolor: 2383748
doSomething: «Function#4| theView_doSomething»
hassetheight: true
hassetwidth: true
height: 40
id: theView
immediateparent: «LzCanvas#5| This is the canvas»
isinited: true
mask: null
nodeLevel: 1
onheight: #theView.onheight
onvisible: #theView.onvisible
parent: «LzCanvas#5| This is the canvas»
width: 40
}
«LzView#0| #theView»
lzx> _
«LzView#0| #theView»
lzx> _.setAttribute("bgcolor", 0x777777);
The last three values the debugger has printed are stored in variables named _, __ and ___.
Up-arrow and down-arrow retrieve this history of commands. Up arrow, return repeats the previous command.
Debug.monitor(who, what) prints out a message each time a particular
property (what) of a particular object (who) changes. Debug.monitor is documented in the developer's guide and is present in 3.1 through 3.4, but not yet present in the DHTML runtime.
And finally, backtracing! Edit the lps.properties file, in $LPS_HOME, to say
compiler.debug.backtrace=true
then you can call Debug.warn('foo'), Debug.info('foo'), or Debug.debug('foo') in your code and it prints a string which you can click on to see the backtrace from that place. If you useDebug.trace(<object>, <method name>) or Debug.monitor(<object>, <attribute name>) the messages that those output (at function entry/exit or on modification of an attribute) will include a backtrace too.
(Thanks to Tucker for implementing and explaining these tools.)
Wednesday, September 06, 2006
Latest developments at Laszlo Systems
Meanwhile, I've been working on an implementation of CSS for OpenLaszlo. Adam Wolff and I have been doing the work in a developer branch, coal. Our CSS implementation is planned to be released as part of OpenLaszlo 3.4. Unlike the bone-deep changes to DHTML programming paradigm with the adoption of CSS, the dominant paradigm for writing OpenLaszlo applications will still be to write lzx classes and scripts. OpenLaszlo, unlike DHTML, was designed from the beginning to be a presentation and interaction language, so it has far fewer empty spots to spackle over with an additional syntax layer than did pre-dynamic HTML. CSS will allow for themes, skinning, and a smoother designer/programmer collaboration workflow.
- We're supporting a big subset of CSS 2.1 selectors: element type, attribute selectors, id selectors, and descendant selectors, while leaving out .class selectors, sibling selectors, pseudo-elements and pseudo-classes.
- CSS rules are evaluated at construct-time to determine attribute values for any attribute of any node (just about).
- We have introduced style constraints to specify how to map CSS style properties onto lzx attributes; these are much like the $once, $always, and $path syntaxes already present in OpenLaszlo.
- There is compiler support for CSS, which feeds the runtime CSS engine.