| One often ends up needing to write support files in order to test or show examples for libraries. Maintaining these support files separately from the library file is an extra chore. It is currently an error to point the compiler at a library file. It would be nice to be able to run a library file as though it were an application file. In the case of a library that is used to hold instances (in order to modularize an application source into multiple files), it's obvious how to do this. In the case of a library that defines classes, some additional knowledge is necessary. I propose that this behavior be changed as follows. There are three incrementally more sophisticated proposals that add capabilities at the cost of complexity. (None of these is at all hard to implement, but the later proposals may be hard to understand.) Basic Proposal It is no longer an error to specify a library file as the main source file for compilation. The behavior is exactly the same as though the document root element has the tag name "canvas" instead of "library". This proposal handles the case where a library file contains standalone instances. For example: mylib.lzx: <library> <window title="Settings"> <button>Okay<button> </window> </library> is compiled as though it were: <canvas> <window title="Settings"> <button>Okay<button> </window> </canvas> when it is the main source file for compilation. Embedded <canvas> tag The <canvas> element is added to the list of element that a library file can contain. The <canvas> tag, if present, must be a child of the document root <library> element. When the library file is included within another file (when it is not the main source file for compilation), the <canvas> element and its contents are ignored. When the library file is the main source file for compilation, it is compiled as though the canvas element were the root element, and it included the library file before its first child. For example: <library> <class name="settings" extends="window" title="Settings"> <button>Okay<button> </class> <canvas title="This is my test case" bgcolor="silver" layout="axis: y"> <settings id="s1"/> <button >Hide</button> </canvas> </library> is compiled as though it were: <canvas title="This is my test case" bgcolor="silver" layout="axis: y"> <class name="settings" extends="window" title="Settings"> <button>Okay<button> </class> <settings id="s1"/> <button >Hide</button> </canvas> when it is the main compilation file. When it is not the main compilation file, it is treated identically to mylib.lzx under the basic proposal. (Note that this proposal and the next one do not allow the developer to insert canvas code that occurs before the library; for example, to define datasets or global functions that must be present by the time the library code is executed. This is certainly a soluble problem, but let's see if the simple version is enough first.) This allows a library file to be used as its own test case, or to carry its own example. Multiple embedded <canvas>s The same as the previous version, except that a library file may contain multiple <canvas> elements. If the file is compiled as a main source file, the first of these canvases is used and the others are ignored. However, the compiler can be directed to use one of the other canvas elements instead, through the use of the 'canvas' selector. This is specified to the browser compiler through the lzcanvas query parameter, and to the command-line compiler through the use of the --canvas argument. A <canvas> element within a <library> may have a @name attribute. If a canvas selector is specified, and the main source file is a <library> file, the value of the canvas selector must match the value of the @name attribute of one of the embedded <canvas> elements (otherwise a compilation error is signalled). In that case, that canvas is used as the matrix, and extended by the library content as specified above. Also, the canvas title, if it is not given, defaults to the canvas name. For example, given: <library> <class name="settings" extends="window" title="Settings"> <button>Okay<button> </class> <canvas title="This is my test case" bgcolor="silver" layout="axis: y"> <settings id="s1"/> <button >Hide</button> </canvas> <canvas name="demo"> <settings/> </canvas> <canvas name="twowindows" layout="axis: y"> <settings/> <settings/> </canvas> </library> If it this file is compiled as the main source file with no canvas selector, it is equivalent to: <canvas title="This is my test case" bgcolor="silver" layout="axis: y"> <class name="settings" extends="window" title="Settings"> <button>Okay<button> </class> <settings id="s1"/> <button >Hide</button> </canvas> If it is compiled with the URL http://localhost:8080/lps-dev/mylib.lzx?lzcanvas=demo or with the command line "lzc --canvas=demo mylib.lzx', it is equivalent to: <canvas title="demo"> <class name="settings" extends="window" title="Settings"> <button>Okay<button> </class> <settings/> </canvas> If it is compiled with the URL http://localhost:8080/lps-dev/mylib.lzx?lzcanvas=twowindows or with the command line "lzc --canvas=twowindows mylib.lzx', it is equivalent to: <canvas title="twowindows" layout="axis: y"> <class name="settings" extends="window" title="Settings"> <button>Okay<button> </class> <settings/> <settings/> </canvas> This allows a library file to carry multiple test cases or examples. |
_______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
