<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
  <head>
    <title>legalsbeta1releasenotesv3</title>
    <expansionState>0,2,4,10,21,23,26,29,34,37,38,40,45,50,52,58,61,68,71,76,78,79,81,83,84,91,94,98,101,106,112,114,119,121,122,128,129,132,134,136,140,142,144,145,149,150,157,158</expansionState>
  </head>
  <body>
    <outline text="Overall Status">
      <outline text="This document: ben shine's working draft as of 12.3.2006"/>
      <outline text="Welcome to the first beta release of OpenLaszlo project &quot;Legals,&quot; which is now officially called &quot;Open Laszlo 4.0 Beta 1.&quot;">
        <outline text="With this B1 release, we invite developers to start developing against our brand new DHTML and heavily revamped Flash runtimes. There have been four preview releases before this beta, PR1 through PR4, each demonstrating major progress but none stable enough for use as a development platform. You'll need to deal with a few rough edges -- many performance improvements remain, there are still significant bugs, and some features remain incomplete -- but we believe that the level of functionality is high enough that the intrepid early adopter will benefit from trying out this release. We plan a B2 release by the end of 2006 that will be incrementally more stable. We will label the B2 our &quot;Developer's Release,&quot; suggesting that with B2 serious development cycles may begin in earnest. The final release of Legals will come in Q1 of 2007. We foresee major focus on performance improvements for B2. &#10;&#10;The 4.0 release is a major re-architecture of OpenLaszlo to support multiple target runtimes, and includes support for Flash 7 and 8 (and 9 in Flash-8 emulation) along with DHTML. Our DHTML support covers the most popular browsers of the moment: Firefox 1.5 and 2.0, Microsoft Internet Explorer 6 and 7, and Safari 2. Other browsers are not officially supported but seem to work fairly well, including Opera 9 and nightly builds of Webkit. (See below (link) for details on supported browsers.)&#10;&#10;Legals is very nearly feature complete. All components are at a testable state with just P2 bugs remaining to be addressed. The Laszlo Foundation Classes (LFC) have been completely refactored and heavily modified to support our multi-kernel architecture, differences between supported JavaScript dialects, and the addition of several significant ECMAScript 4 features to the compiler and language support library. The kernel API is fully documented and nearly complete. The reference documentation tools have been revised to support multiple runtimes and ECMAScript 4 syntax. A more detailed description of the changes in this release is to be found below.&#10;&#10;There are still a variety of missing elements and gotchas. The rest of this document describes these issues in detail. See (link)&#10;&#10;We are working to provide as many Flash-centric features as possible in DHTML -- preliminary support for &lt;drawview&gt; is in this release -- but several features familiar to OpenLaszlo developers are not currently scheduled for 4.0B1 at all. These include swf embedding, audio/video embedding, streaming audio/video, persistent connection, and snippets.&#10;A working 3.x application will probably not work unmodified in 4.0B1, but, there are well-known techniques for coping with this. Some changes are required to adapt to the new runtime, plus a few changes are necessary to temporarily work around bugs and missing features. JavaScript in browsers is generally more strict than in Flash, so certain common coding practices no longer work or are deprecated in Legals. More information on transitioning from 3.x is available below.">
          <outline text="Read this before using Open Laszlo 4.0 Beta 1">
            <outline text="Existing 3.x Open Laszlo applications will probably not work immediately with 4.0, but porting should be straightforward. See the section on porting from 3.x for details. "/>
            <outline text="swf assets will not display in DHTML. Swf assets must be replaced with bitmap images. We recommend png. See below for a png conversion tool."/>
            <outline text="The tools for preparing a SOLO (standalone) application are still under development."/>
            <outline text="Performance is slower than 3.4.x and it will be improved. The swf runtime for 4.0 is somewhat slower than the swf runtime for 3.4; the DHTML runtime for 4.0 is considerably slower than the swf runtime for 4.0. This release is a feature-complete release, and not a performance-focused release. The following two releases, Beta 2 and 4.0 Official, will focus on performance improvements."/>
            <outline text="Post to laszlo-dev@openlaszlo.org &lt;mailto:laszlo-dev@openlaszlo.org&gt; with questions and comments. Please report bugs, especially regressions."/>
          </outline>
        </outline>
      </outline>
      <outline text="More information">
        <outline text="The rest of this document first describes major changes since 3.3.x and 3.4, and then lists specific issue names and numbers. "/>
        <outline text="General information about Legals may be found here. www.openlaszlo.org—legals &lt;http://www.openlaszlo.org/legals&gt;"/>
        <outline text="The Legals project wiki is  here.  wiki.openlaszlo.org—Legals_Project_Plan &lt;http://wiki.openlaszlo.org/Legals_Project_Plan&gt;"/>
        <outline text="A Legals FAQ is available  here. wiki.openlaszlo.org—Legals_FAQ &lt;http://wiki.openlaszlo.org/Legals_FAQ&gt;"/>
        <outline text="Build instructions are here (link)"/>
        <outline text="Nightly builds are here (link)"/>
        <outline text="Demos are here (link)"/>
        <outline text="Documentation is here (link)"/>
        <outline text="Official distributions are available here (link)"/>
        <outline text="The bug database is available here (link)"/>
        <outline text="Getting Involved">
          <outline text="(If you would like to get involved in qualifying Legals for these or any other browser, please contact us by visiting www.openlaszlo.org—cfaq.) &lt;http://www.openlaszlo.org/cfaq.)&gt;"/>
        </outline>
      </outline>
      <outline text="Marquee Demos">
        <outline text="LzPix: a flickr photo browser which looks identical in DHTML and Flash runtimes. (link)"/>
        <outline text="Calendar: a calendar application which looks nearly identical in DHTML and Flash runitmes. (link)"/>
      </outline>
      <outline text="Browsers x Runtimes x Operating Systems">
        <outline text="TODO bshine: make this diagram pretty"/>
        <outline text="Runtime 	 Operating Systems 	 Support Level 	 OL Kernel 	 Notes&#10;Flash 7 	Windows/Mac	A 	swf 	version 7r68 or later&#10;Flash 8 	Windows/Mac 	A 	swf 	incl. Flash9 emulation mode&#10;Internet Explorer 6 	Windows 	A 	dhtml 	&#10;Internet Explorer 7 	Windows 	A 	dhtml 	&#10;Firefox 1.5 	Windows/Mac/Linux 	A 	dhtml 	&#10;Firefox 2.0 	Windows/Mac/Linux 	A 	dhtml 	&#10;Safari 2.0 	Mac 	A 	dhtml 	&#10;Flash 7 	Linux 	B 	swf 	&#10;Flash Lite 2 	Embedded/Mobile 	B 	swf 	&#10;WebKit nightly 	Mac 	B 	dhtml 	&#10;Mozilla nightly 	Windows/Mac/Linux 	B 	dhtml 	&#10;S60WebKit 	Symbian Series 60 	B 	dhtml 	&#10;Opera 8 	Windows/Mac 	B 	dhtml 	&#10;Opera 9 	Windows/Mac 	B 	dhtml 	&#10;Flash 5 	Windows/Mac 	C 	dhtml 	no longer supported&#10;Flash 6 	Windows/Mac 	C 	dhtml 	no longer supported&#10;Flash 9 (native) 	Windows/Mac 	C 		support planned in 2007&#10;Flash Lite 	Embedded/Mobile 	C 		based on Flash5; not supported&#10;Internet Explorer 5 	Windows/Mac 	C 		too old; not supported&#10;&#10;Support Levels&#10;&#10;A -- Fully supported&#10;B -- Not supported, but may work; bugs tracked and contributions accepted&#10;C -- Incompatible (doesn't run for a significant technical reason)"/>
      </outline>
      <outline text="Roadmap (plans for future and related versions)">
        <outline text="4.0 Beta 2 will be focused on improving performance. "/>
        <outline text="We are beginning to plan out Osprey, the successor to 4.0, which will provide native Flash 9 support. (Note that 3.x and Legals both support Flash 9 using that player's Flash 8 emulation mode.) And members of the OpenLaszlo community have announced work on two more runtimes: project Orbit, the Sun/Laszlo partnership to produce a J2ME target runtime, and an experimental SVG runtime from OpenLaszlo team member Henry Minsky."/>
        <outline text="Another future version is seaswirl, which is components improvements. Seaswirl is not yet scheduled."/>
        <outline text="4.0B1 does not include the Orbit runtime; watch (link) for news on Orbit."/>
      </outline>
      <outline text="Credits">
        <outline text="4.0B1 includes contributions from (TODO bshine) and the core Open Laszlo team."/>
        <outline text="The community has reported many bugs, some of which have been fixed. Thanks to (TODO bshine) for the bug reports. We encourage the community to file reproducible, testable bugs, preferably written in lzunit or lztest. See below for an introduction to lzunit and lztest. "/>
      </outline>
    </outline>
    <outline text="Feature Status">
      <outline text="Just Works">
        <outline text="The core Open Laszlo functionality works in 4.0B1: views, nodes, resources, layouts, data, components, events, and focus. The three large demos included in this release demonstrate that 4.0B1 is mature enough to support lots of application development. LzPix (link) shows off animated user interfaces, data binding, REST api usage, image scaling, and complex javascript. The Calendar demo shows off data binding and an animated user interface. "/>
        <outline text="Tons of Documentation and Examples">
          <outline text="Laszlo Explorer"/>
          <outline text="Laszlo in Ten Minutes"/>
          <outline text="Developer's Guide"/>
          <outline text="Reference Guide"/>
          <outline text="Examples we like">
            <outline text="Weather"/>
            <outline text="Amazon"/>
            <outline text="LzPix"/>
            <outline text="Calendar"/>
          </outline>
        </outline>
      </outline>
      <outline text="New Features">
        <outline text="New compiler flags (TODO ptw)"/>
        <outline text="autopng">
          <outline text="Automatically load png files instead of swfs if present.&quot;It should be explained that &#10;Placing a file with the same name in that parent directory overrides the version in the autoPng directory.&#10;Just to clarify, the compiler uses the same search path for swf-&gt;png. It does not create png from swf automatically. The autopng files are created by an offline process."/>
          <outline text="DHTML cannot display swf assets. As a convenience, the server and compiler automatically search for a corresponding png file if a swf file is referenced in the DHTML runtime. To use this mechanism in your own code, create a png file with the same basename as the swf file, and place it in the same directory as the swf resource you want it to replace."/>
          <outline text="&lt;resource file=&quot;resources/foo.swf&quot; /&gt;"/>
          <outline text="When compiled into a swf runtime, this will still load resources/foo.swf as expected. When compiled into a DHTML runtime, this will try to load resources/foo.png."/>
          <outline text="The Open Laszlo distribution also makes use of png replacements for swfs, generated by an offline, batch tool. If resources/foo.png is not present, the server will try to load resources/autoPng/foo.png. The autoPng-generating-tool used by the Open Laszlo developers is not yet documented for re-use. "/>
        </outline>
        <outline text="Wrapper pages">
          <outline text="Browser detection code in the wrapper pages will issue a warning at startup in non-A-list browsers."/>
        </outline>
        <outline text="canvas.versionInfo"/>
        <outline text="javascript &quot;in&quot; operator:">
          <outline text="iterating through data structures -- (TODO bshine: test this code) this: for (var c in cats) { var cat = cats[c]; Debug.write(&quot;I have a cat whose name is &quot;, c);"/>
          <outline text="iterating across attributes of an object. (TODO bshine: test this code) var obj = new View( ... ); for (var attr in obj) { Debug.write(&quot;obj has an attribute &quot;, attr, &quot; with value &quot;, obj[attr]; }"/>
        </outline>
      </outline>
      <outline text="Runtime Differences">
        <outline text="Taken from the wiki: wiki.openlaszlo.org—Runtime_Differences &lt;http://wiki.openlaszlo.org/Runtime_Differences&gt;"/>
        <outline text="Visual transformations we can't (yet) do in dhtml are:&#10;&#10;    * Rotation - may be possible in Firefox with SVG&#10;    * Stretching nested subviews - likely possible in Firefox &#10;&#10;Visual transformations requiring extra runtime resources (IE only):&#10;&#10;    * Opacity that affects subviews&#10;    * Displaying PNG (and possibly GIF) images with alpha &#10;&#10;DHTML-specific limitations requiring source-level lzx changes:&#10;&#10;    * Can't set the opacity of a view that contains text - but can set a subview's opacity (IE only)&#10;    * Stretches only works on leaf views with resources&#10;    * Rotation - may be possible in Firefox with SVG&#10;    * Stretching nested subviews - likely possible in Firefox &#10;&#10;Fonts&#10;&#10;    * DHTML does not support font inclusion.&#10;          o If an LZX app uses the &lt;font&gt; tag to import a font, and is compile it for DHTML or other target which doesn't support font inclusion, the compiler will give a warning &quot;DHTMLWriter does not support importing fonts.&quot;&#10;&#10;Keyboard events&#10;&#10;    * In DHTML, control, shift and alt are treated as 'modifer' keys. As a result, they are only sent when another key is pressed or a mouse event occurs. &#10;&#10;The Persistent Connection Manager&#10;&#10;    * In flash, this is a provisional feature with limited support&#10;    * In DHTML, does not work. "/>
        <outline text="DHTML in Internet Explorer 6 is problematic, as is well-known by the web development community. Kernel and LFC support for IE6 is the most likely to have bugs. "/>
      </outline>
      <outline text="Partially Supported">
        <outline text="DrawView only supported in Firefox. It partially works in Safari. "/>
        <outline text="MP3 playback"/>
      </outline>
      <outline text="Present but Not Qualified">
        <outline text="Two major feature sets developed for Open Laszlo 3.4 have been merged into the code for 4.0, but not yet qualified in 4.0B1: CSS (Cascading Style Sheets) and Video. "/>
        <outline text="Video: (TODO jrs) Video support is present in Open Laszlo 3.4, but not tested or qualified in 4.0B1."/>
        <outline text="CSS provides a cascading style sheets implementation for styling Open Laszlo views and data. The CSS system has been extensively tested in 3.4, and is useful for compile-time skinning of applications. This is implemented in 3.4 as part of the LFC, and it will require changes to work in the 4.0 LFC implementation. This feature is separate from the DHTML runtime's use of css to set div properties. "/>
        <outline text="The SVG (Scalable Vector Graphics) runtime is experimental."/>
      </outline>
      <outline text="Not yet ported to DHTML runtime">
        <outline text="SOAP, XML-RPC, Java-RPC have not yet been ported to DHTML"/>
      </outline>
      <outline text="Dropped Features from 3.x">
        <outline text="Rich text editor">
          <outline text="lps/components/extensions/rich-text will not ever work in DHTML. Code that goes into the &quot;extensions&quot; directory is, by definition, runtime-specific. If you want a rich text editor for DHTML, we suggest embedding an existing DHTML text editor such as TinyMCE tinymce.moxiecode.com &lt;http://tinymce.moxiecode.com/&gt;"/>
        </outline>
        <outline text="Dropped Demos">
          <outline text="Dashboard"/>
        </outline>
      </outline>
    </outline>
    <outline text="Architecture and Language Changes">
      <outline text="Porting from 3.x to Legals">
        <outline text="There will be very little change in the Javascript used in script blocks and method definitions in Open Laszlo applications. The main changes to Javascript in support of SWF9 and EcmaScript 4 are in the LFC sources to take advantage of the faster class system in 4.0. This change will automatically be handled for javascript in lzx code. If your code makes fancy use of the class system, it has a potential to break in 4.0, but we're not aware of breakages caused by the class system."/>
        <outline text="swf6 is no longer supported. That means applications will not run in Flash Player 6, and that the lzr=swf6 query argument is now an error."/>
        <outline text="swf assets won't work in DHTML. To display a swf asset, you'd need the flash player; we're not using the flash player in DHTML, so, swf assets just won't appear. The solution here is to use bitmap assets instead of swf's. The straighforward but painful way to do this is to convert your swf assets to bitmaps. The clever way to do this is to take advantage of the &quot;autoPng&quot; feature; see New Features, above. (link)"/>
        <outline text="Applications which use drawview will probably not work well in all runtimes yet. It is probably too soon to start porting applications which use drawview. Wait for Beta 2."/>
        <outline text="DHTML doesn't support embedding fonts; swf does. If you try to embed a font and compile for dhtml, you'll get a compile warning, and the text will look ugly, or it won't appear at all."/>
        <outline text="The flash runtime is permissive about derefrencing a null reference and getting properties on an undefined object. DHTML blows up if you do this.Because it was permitted in swf, lots of code doesn't check for null. All the places that don't check for null need to be tracked down and fixed, both in the LFC, the components, and application code. "/>
      </outline>
      <outline text="Introducing the Kernel...">
        <outline text="TODO bshine The Layer Cake Diagram!"/>
        <outline text="The best documentation for the kernel api is at http://wiki.openlaszlo.org/KernelAPIProposal &lt;http://wiki.openlaszlo.org/KernelAPIProposal&gt;"/>
      </outline>
      <outline text="What does the kernel refactor mean for application developers?">
        <outline text="The refactoring should be almost transparent to application developers, except for a few changed API's, which this document (the release notes) describes."/>
        <outline text="Most application developers build with components and classes, not the LFC API. Most application developers will not have to go near the kernel API's; the kernel API's are primarily for developers who are working on implementing an additional runtime. "/>
      </outline>
      <outline text="Compiler flags for multiple runtimes"/>
      <outline text="Wrapper page changes">
        <outline text="The wrapper pages have been substantially changed. There is a new javascript bridge and flash embedding based on dojo.flash www.dojotoolkit.org &lt;http://www.dojotoolkit.org/&gt;Related to LPP-2664 update deployment wrappers for legals, LPP-3181, and LPP-3182"/>
        <outline text="TODO jrs: please explain this more"/>
      </outline>
      <outline text="Resource loading changes">
        <outline text="(TODO: insert description from pga here)"/>
      </outline>
      <outline text="TODO ptw: Differences in the meaning of undefined, null (see lzunit tautologies test)"/>
      <outline text="TODO ptw:  Differences in semantics of boolean comparisons (see lzunit tautologies test)"/>
      <outline text="TODO ptw: List javascript functions that were not available in 3.3 but are now available in 4.0."/>
      <outline text="For LFC Developers: Language changes">
        <outline text="The &quot;class system&quot; underlying the Laszlo Foundation Changes has been extensively redesigned. If you are an Open Laszlo application developer or component developer, you don't need to know about this at all; it is transparent to you. In fact, you can't even get to the new class system unless you're working in the actual LFC code."/>
        <outline text="The Laszlo Foundation Classes (LFC) rely quite a bit on the new class system. If you work on the LFC, you will want to understand these changes. If you don't know whether you work on the LFC, you probably don't. "/>
        <outline text="These new language features have been implemented in the LFC core to support (and extend) Javascript 2 `class` declarations portably. The LFC developer can now write Javascript 2 `class` declarations, rather than creating their classes using Javascript 1 prototypes.  The Javascript 2 `interface` declaration is supported, but not enforced (that is, there is no compile or runtime checking that a class actually implements an interface)."/>
        <outline text="We have extended Javascript 2 to support `mixin` declarations.  See [BrachaCook90](http://portal.acm.org/citation.cfm?id=97982&amp;coll=portal&amp;dl=ACM &lt;http://portal.acm.org/citation.cfm?id=97982&amp;coll=portal&amp;dl=ACM&gt;) for a formal definition of mixins.  Informally, mixins are 'interfaces with implementation'.  They take the same form as a `class` declaration, but are introduced by the keyword `mixin`.  They are added to a class similarly to an interface, but with the keyword `with`.  They are allowed to add methods and fields to the class they are mixed in to.  They are allowed to override methods in the superclass and other mixins, but note many O-O theorists feel this generality leads to [inscrutable programs.][1]"/>
        <outline text="Traits &lt;http://www.iam.unibe.ch/~scg/Research/Traits/&gt;, which is the term we used informally when discussing our extension of the language, has a formal definition in O-O theory that side-steps the complexity of mixins and overriding by prohibiting state and overriding in `trait`s.  We do not enforce such restrictions, although the designer can impose such a discipline on themselves.&#10;"/>
        <outline text="The new class regime simply allows us to support the LXZ class system and Javascript 2 `class` declarations in a portable fashion across more runtimes. Eventually, we will expose `mixin`s at the LZX API and the application programmer will be able to use that feature to modularize their programs.  We feel this will be highly beneficial in the design of UI components which tend to have shared behavior in patterns that single-inheritance subclassing cannot easily describe without a lot of duplicated code.">
          <outline text="multiple_runtimes"/>
        </outline>
      </outline>
    </outline>
    <outline text="Deployment changes">
      <outline text="We support new query parameters to request lzx applications to be compiled to each runtime. The most interesting new query parameter is lzr=dhtml, which means, compile this application as dhtml."/>
      <outline text="We recommend tomcat 5.0.28 or 5.0.30."/>
      <outline text="We have not qualified against other servlet containers, but we have heard reports that Glassfish, JBoss, and Tomcat 5.5 all work."/>
      <outline text="We include an example of how to configure Tomcat to use gzip compression for serving up javascript; deployers will need to modify their servlet container's configuration to enable javascript compression. setting up your web server to gzip javascript and dhtml might be tricky. The tomcat that ships with this release is not configured to gzip javascript and dhtml."/>
    </outline>
    <outline text="Tools Changes">
      <outline text="The tools we use to build, test, and analyze Open Laszlo have matured significantly with the 4.0 Beta 1 Release. We have changed to using Subversion from Perforce, for source control, in order to enable a more open development process. The build is now based on ant 1.6.5, rather than ant 1.5. We have created a new testing tool, lztest, for automated testing, without dropping lzunit, for application- and component-level testing. We have created a suite of benchmarks and benchmark analysis tools. "/>
      <outline text="Changes visible to application builders">
        <outline text="Debugging changes">
          <outline text="For debugging the DHTML runtime, we recommend the FireBug extension to FireFox. If Firebug reports an error (with a little tiny red X in the bottom right hand corner of your firefox window) then there is probably a bug in your code or an  Open Laszlo bug. The errors reported by FireBug can be very obscure, but they usually happen when you are dereferencing a null pointer. "/>
          <outline text="The Debug class now supports new methods for formatting and outputting information: Debug.write, Debug.warn, Debug.info, Debug.format."/>
          <outline text="We have a brand new DHTML debugger."/>
          <outline text="Cool new auto-completion and history. (TODO ptw, please describe.)"/>
          <outline text="Remote console debugger (TODO henry: can you describe what this does and why?)"/>
        </outline>
      </outline>
      <outline text="Changes visible to Open Laszlo platform developers (building and developing the platform itself)">
        <outline text="Build requirements">
          <outline text="We support building under Java 1.4 and 1.5. We haven't tried 1.6. We recommend building with Java 1.5. "/>
          <outline text="We now require Subversion 1.3 or later and ant 1.6.5 or later to build from source. See (wiki)"/>
        </outline>
        <outline text="Documentation tools">
          <outline text="The &quot;doctools&quot; have been rewritten in java and XSLT, replacing the python transformation pipeline in 3.4 and earlier. "/>
        </outline>
      </outline>
      <outline text="New Test Systems">
        <outline text="The test directory does not ship in Open Laszlo distributions, but it is available from subversion with svn.openlaszlo.org—test &lt;http://svn.openlaszlo.org/openlaszlo/branches/legals/test/&gt;"/>
        <outline text="lztest">
          <outline text="lztest is a tool for testing the compiler and the LFC. Tests for it are not included in the distributions, but they are run for each build. lztest allows the same test code to be executed in swf, in dhtml, or from a command line by using the rhino runtime. The command line lztest facilitates automated build testing."/>
          <outline text="lzunit has been updated to work in 4.0B1 in the swf runtime and the dhtml runtime."/>
        </outline>
        <outline text="megatest"/>
        <outline text="xmlunit and junit">
          <outline text="JUnit tests exist for some of the compiler and some of the doctools. The doctools also use xmlunit for unit testing. Neither of these are visible to application developers. "/>
        </outline>
        <outline text="performance analysis">
          <outline text="The test directory for 4.0B1 includes suites of benchmarks to compare runtime performance in different client environments. These tests are in test/lfc/perf, available from subversion but not in the distributions. The performance suite is not yet supported for external users; we recommend using lps/utils/performance/measure.lzx. "/>
        </outline>
      </outline>
      <outline text="Infrastructure changes (Laszlo Systems processes visible to the outside world)">
        <outline text="Nightly builds">
          <outline text="We run nightly builds of each active development branch, and deploy these builds to labs.openlaszlo.org. The nightly build of &quot;legals&quot; development is at labs.openlaszlo.org—legals-nightly &lt;http://labs.openlaszlo.org/legals-nightly/&gt; Think of this as &quot;tip-of-trunk&quot; most recent builds."/>
          <outline text="Archived source for all 3.4.x builds and 4.0.x builds are tagged in Subversion as svn.openlaszlo.org—builds &lt;http://svn.openlaszlo.org/openlaszlo/builds/&gt;"/>
          <outline text="Installers for recent 3.4.x and 4.0.x builds are available at download.openlaszlo.org—nightly &lt;http://download.openlaszlo.org/nightly&gt;"/>
        </outline>
      </outline>
    </outline>
    <outline text="Digging Deeper">
      <outline text="Don't rely on implicit this.">
        <outline text="A common but unreliable lzx practice is to relying on scope to map a variable name to an attribute of the current object. We discourage this practice; you should always explicitly say &quot;this.&quot; on the left-hand side of any assignment. "/>
        <outline text="The compiler can help you find code which reaches into the global scope; compile your application with `lzc -DwarnGlobalAssignments`, the compiler will print a warning for every global assignment that your program makes. If you intend to make a global assignment, you can silence the warning by explicitly using `global.attr =`."/>
        <outline text="'implicit this' is a term we use to describe the behavior of free references in LZX methods and handlers.  In LZX classes, the object bound to `this` is implicitly 'in scope' in all methods and handlers, as it is in Java, but not in Javascript.  We added this feature to LZX because we felt it led to more intuitive and compact code. "/>
        <outline text="What this means is that in any method or handler in a class you can refer to the class attributes by name directly, without the prefix `this.`.  (Hence the nickname 'implicit this'.)  A concrete example:&#10;&#10;&lt;class name=&quot;foo&quot;&gt;&#10;  &lt;attribute name=&quot;attr&quot; value=&quot;42&quot; /&gt;&#10;&#10;  &lt;method name=&quot;implicitAttrValue&quot;&gt;&#10;    return attr;&#10;  &lt;/method&gt;&#10;&#10;  &lt;method name=&quot;explicitAttrValue&quot;&gt;&#10;    return this.attr;&#10;  &lt;/method&gt;&#10;&lt;/method&gt;&#10;&#10;The two methods will return the same value.  NOTE: you should _not_ rely on implicit this on the left-hand side (LHS) of an assignment expression.  Consider:&#10;&#10;&lt;class name=&quot;bar&quot;&gt;&#10;  &lt;attribute name=&quot;attr&quot; /&gt;&#10;&#10;  &lt;method name=&quot;implicitSetAttrValue&quot;&gt;&#10;    attr = 7;&#10;  &lt;/method&gt;&#10;&#10;  &lt;method name=&quot;explicitSetAttrValue&quot;&gt;&#10;    this.attr = 7;&#10;  &lt;/method&gt;&#10;&lt;/class&gt;&#10;&#10;Because `attr` is not initialized, the implicit method may not find `attr` in the instance and will set the global variable `attr` instead.  You should _always_ explicitly use `this.` on the left-hand side of any assignment.  &#10;"/>
      </outline>
      <outline text="Developer console is still flash."/>
      <outline text="The oft-misinterpreted codename Legals will still be used. (link to cultural reference)"/>
    </outline>
    <outline text="Tracked Bugs, Issues, Fixes, etc">
      <outline text="known issues from ben">
        <outline text="This distribution may contain unused resources. Expect the Beta 2 and Final release to be much smaller."/>
      </outline>
      <outline text="mkratt is building this section"/>
    </outline>
  </body>
</opml>
