Best practices
From OpenLaszlo
Here are some best practices, in no particular order right now. As this list grows it would be good to order them from beginner to advanced.
Contents |
Test first and often
When developing an application, make a simple test file for each class (or group of classes) to make it easier to develop initially and isolate bugs when they are found in the larger application.
Don't wait till your app is almost finished to think about size and speed. To quickly get a good sense of startup time add <inittimer/> to your app or test file. This will show startup time in milliseconds. (Be sure to run it a few times, the first time will always be slowest)
One class per file
Name the file classname.lzx. This is a guideline, rather than a strict rule. Sometimes it makes sense to collect a few small classes in a file, but most of the time, especially as your classes grow, you'll be happy you did this. It makes it easy to find what you're looking for, especially as your project gets big. It also makes it easier to reuse code on your next project.
No debugger warnings
Make sure your code runs without debugger warnings. Here are a few common reasons for warnings:
- When you write a setter, it may be invoked before subviews are created and before your init method, to install an initial value. This can be a problem if your setter depends on other attributes of the node. You should avoid writing setters that depend on the state of the node; if you must, you can check this.isinited (which will be true when subviews have been created). If you are writing a component (a subclass of basecomponent), you can check this._initcomplete which is set to true in basecomponent's init, or set your own flag. If needed, you can then call the setter from init.
- Declare all your events:
<event name="onfoo" />
- If you did not create the event, and hence don't know that it was declared, check for its existence before sending.
<method name="setfoo" args="newfoo">
this.foo = newfoo;
if (this.onfoo) this.onfoo.sendEvent(newfoo);
</method>
Managing Screen Space
There are three ways to manage screen space in a Laszlo application: constraints, events and layouts. Each has an appropriate use.
Handle events with methods in classes
When writing a class, if you define an event handler, handle it with a method, so an instance or subclass has the option of either adding a handler or overriding the handler behavior. Instead of:
<handler name="onkeyup">
// superclass code here
</handler>
Say:
<handler name="onkeyup" method="handleKeyUp" />
<method name="handleKeyUp" args="keycode">
// superclass code here
</method>
If an instance or a subclass defines a handler that is also defined in the superclass:
<handler name="onkeyup">
// subclass or instance code
</handler>
both handlers are executed and may be executed in any order. You want to provide the option of controlling whether the behavior of the superclass happens before or after the code you are adding (or not at all). If the handler behavior is written as a method rather than the body of the handler, instances and subclasses have the option of overriding the handler method (in addition to defining additional handlers) to get this control. For example:
<method name="handleKeyUp">
// your code here
// optionally call the super method passing all arguments
super.handleKeyUp.apply(this, arguments)
// or your code here
</method>
For the same reason, override init and construct, rather than using oninit and onconstruct when you create a class.
Add an attribute, rather than just an event
It's convenient to use events for notification and its a good idea; however, if you are creating a custom event, consider adding an attribute instead. With an attribute, you store the data in a well-known place and get an event for free.
Background: implicit and built-in events.
