| Sign In/My Account | View Cart |
Exploring Laszlo Classes, Attributes, and Events
Pages: 1, 2
The sample code now has the necessary tool set to explore the
linkage between attributes and events a bit further. The button
that was used to test the alert can also be used to
set the attributes that I have defined earlier. I want to show how
setting those attributes will fire the corresponding
onchange methods.
What follows is a method, respondToButton(), that will be called when the showAlert button is
clicked.
<canvas width="800" debug="true">
<debug x="450" y="0" height="300"/>
<class name="test">
<attribute name="a1" type="string"/>
<attribute name="b1"/>
</class>
<!--Instantiating a class-->
<test name="testInstance">
<!--Demonstrating an onchange for attribute event-->
<method event="ona1" name="ona1Method">
Debug.write("hey this works");
</method>
</test>
<!-- Simulating an alert -->
<!-- A modal alert dialog -->
<alert name="myalert" width="100" y="100">
hi - initial text
</alert>
<!-- A method to work the modal dialog -->
<method name="showAlert" args="displayText">
canvas.myalert.setAttribute("text",displayText);
canvas.myalert.open();
</method>
<!-- Testing the alert function -->
<button onclick="canvas.respondToButton()">Show Alert</button>
<method name="respondToButton" >
//Prepare a string
var somestring =
"Hey, I am setting the a1 attributes value";
//Write a debug to see it
Debug.write(somestring);
//Call the alert to see it
showAlert(somestring);
//Go ahead and set the attribute
canvas.testInstance.setAttribute("a1",'satya');
//The above will fire an event causing
//"ona1Method" to execute.
//You will see this in the debugger
</method>
</canvas>
Notice how the button click sets the attribute of the
testInstance object that is declared using its class
test. One common mistake while writing an LZX method
is to put braces after a method's name; you don't need them.
When you run this example, clicking the button brings up the alert seen in Figure 1.

Figure 3. Event-firing example
Laszlo also allows a <script> tag to define
functions and other procedural logic. To show this, let me modify
the code above to include some scripting and briefly note the
characteristics of an LZX script.
<canvas width="800" debug="true">
<debug x="450" y="0" height="300"/>
<!-- The previous respond method -->
<method name="respondToButton" >
//Prepare a string
var somestring =
"Hey, I am setting the a1 attributes value";
//Write a debug to see it
Debug.write(somestring);
//Call the alert to see it
showAlert(somestring);
//Go ahead and set the attribute
canvas.testInstance.setAttribute("a1",'satya');
//The above will fire an event causing
//"ona1Method" to execute.
//You will see this in the debugger
</method>
<!-- Your method rewritten as a script -->
<script>
function respondToButtonUsingScript()
{
var somestring =
"Hey, I am setting the a1 attributes value";
Debug.write(somestring);
showAlert(somestring);
canvas.testInstance.setAttribute("a1",'satya');
}
</script>
<!-- Button now calling the global script function -->
<button onclick="respondToButtonUsingScript()">
Show Alert
</button>
<class name="test">
<attribute name="a1" type="string"/>
<attribute name="b1"/>
</class>
<!--Instantiating a class-->
<test name="testInstance">
<!--Demonstrating an onchange for attribute event-->
<method event="ona1" name="ona1Method">
Debug.write("hey this works");
</method>
</test>
<!-- Simulating an alert -->
<!-- A modal alert dialog -->
<alert name="myalert" width="100" y="100">
hi - initial text
</alert>
<!-- A method to work the modal dialog -->
<method name="showAlert" args="displayText">
canvas.myalert.setAttribute("text",displayText);
canvas.myalert.open();
</method>
</canvas>
Laszlo's script is similar to JavaScript and follows similar, if
not the same, conventions. In Laszlo, a script tag is allowed
only inside of the root canvas object and nowhere else. Any
code inside of the script, unless it is a function, is executed
immediately. That means that a script tag can include code that
is not inside of any function. I tend to call this sort of
code an "inline code segment."
Needless to say, a script tag can contain function
definitions. These functions are considered global. In contrast, an
LZX's methods belong to the respective nodes under which they are
defined. For instance, a method that is defined using a method tag
inside of the root canvas belongs to the canvas object and is scoped
and named accordingly.
Inside of a script, you can use Java-style (//) line
comments. Because the script tag is inside of another XML tag, it
is sometimes necessary to include the body of the script in a CDATA
section to avoid conflict with any < or > characters.
Just like in JavaScript, if a variable is declared without a
var, then that variable is considered global. It is
better to declare variables with a var scope.
|
Related Reading
Java and XML |
What I have covered so far about Laszlo falls under language
fundamentals. LZX is a fusion of three language concepts: XML, OO
programming, and JavaScript. You will need to spend some time with
LZX to know how these three concepts are melded together,
especially in the use of instance methods. Also, in JavaScript, the
terms object, dictionary, and array can be used synonymously: this
idea is used more extensively in LZX. You will need to brush up
on these concepts of JavaScript one more time to develop successfully
in Laszlo.
I also have touched briefly on Laszlo's visual programming model, involving components and events. Obviously, there is a lot more to the visual programming side if you want to do practical programs. In particular, you will need to master the various visual components that come with Laszlo. For example, you'll find a grid control and a tree control among the list of components that you can use to build your applications.
One area I haven't even touched in this article is the data handling side of Laszlo. It uses data binding and XML navigation extensively. Briefly, Laszlo uses URLs to retrieve XML data sets that are bound to visual controls. The relationship between the UI and the data is lot closer. Data affects the UI much more substantially in Laszlo. For example, a UI component bound to an XML node that has siblings will get replicated (if needed).
This introductory article gave you a starting point for experimenting with Laszlo and starting to explore it. The Laszlo documentation links in the Resources section of this article are a good place to start reading more about the language elements. I also keep running notes on Laszlo as I experiment with it, and keep Laszlo sample code on my weblogging system "akc."
Satya Komatineni is the CTO at Indent, Inc. and the author of Aspire, an open source web development RAD tool for J2EE/XML.
Return to ONJava.com.
Showing messages 1 through 5 of 5.
"1. It runs slow as molasses in winter"
I am yet to try for a large project. But I am fairly confident that if I manage the client architecture well and keep it mainly gui intensive I might be able to accomplish what I need to do. I am encouraged somewhat because the laszlo demos are fairly complex and they respond reasonably well. Flash being the runtime I can imagine the process being slow. But I am hoping it will be fast enough for hybrid content.
"2. It requires you to learn its own markup language, which encourages a mixture of style, structure and logic "
Yes. It is a new language and a slightly different paradigm as well. It is either this or learn the low level graphical apis such as swing or any of its equivalents. The higher level abstractions such as XUL or XAML or LZX appeals to me because they expose higher level semantics for component based graphics programming. LZX is fairly nice and fairly easy to learn. In addition architecturally anything you learn here you may be able to apply in case of XUL or XAML or any similar technologies.
"3. I hate getting tied to a plugin when I don't need it"
I also wish I could do this (well) with out a plug in. Or even if I need a plugin, I could do this with a more general purpose plug in such as Java. There are no technical difficulties for doing this in Java on the client. But somehow I haven't had a good experience with java plugins in browsers, not to mention the increasing size of the java client. I am hoping in the near future this can be resolved and some of these technologies could use java graphics api as the base.
"4. This seems to try to side-step all standards web developers fight
for (at least some of us fight for...)"
Standards are good, but we have got to see the practical side of it as well. I have worked with SVG for sometime. We have developerd a visio like graphics package on the web using this technology. It was hard to do as the tools are lacking. But Flash seem to be the defacto standard in this space. They have more tools, more development and more traction.
"5. Now that we have
href="http://freshmeat.net/search/?q=ajax§ion=projects&Go.x=0&Go.y=0">AJAX-centric
toolkits starting to show up on the scene, do we really need
something that depends on a closed-source plugin from a single company
in order to run something stylish?"
I have just started hearing about AJAX. I can't comment on this in greater detail. From what I hear using the existing technolgoies such as javascript and html it will save the roundtrips to the server. It is definitely a great fit for html applications. There are cases where I can live with the server side latency, but I want to implement such things as drag and drop, etc on the client side. A direct api that can address this (imho) is a better choice.
"6. The more complex the Laszlo app, the more my browser freezes (not
exactly running an ancient machine, either)"
Hopefully Laszlo can address these and fix them as things progress.
"I may have missed some more of its good points, but it just seems an
awful lot to me like OpenLaszlo tries to re-create a browser inside a
plugin, within the browser."
if html is originally designed with user controls in mind perhaps the browser could have been used for this. But in my mind it was meaning to solve the publishing puzzle while providing the limited set of user controls as an add on.
My goal of using Laszlo is what it is good for. Richer controls where they are needed and use html for the rest.
In my opinion there is going to be shift in GUI programming. Laszlo or XUL or XAML is not really about the client and server at all. It is a client technology. Which means I foresee a similar architecture being used for developing standalone client side applications as well. I see a higherlevel apis that sit on top of swing and provide a simpler fluid programming environment.