Constraints（openlaszlo）

constraint 表示可变的变量赋值形式

In LZX, a constraint is an attribute whose value is a function of other attribute values. The syntax for coding a constraint is

$when{expression}

where:

• $ is the token indicating a constraint

• when is an optional compiler directive: immediately, once, or always. $always{expression} can be abbreviated to ${expression}

• { and } are tokens delimiting the expression to be evaluated

• expression is a JavaScript expression

As we have seen above, whenever the value of an attribute changes, its on event is generated. Because a constraint is an attribute whose value is dependent upon the values of one or more other attribute(s), the value of the constraint is recalculated whenever it receives the on event for the attributes on which it depends.

Consider

<view name="someView" 
      width="${someAttribute + someOtherAttribute}" 
 />

The value of someView.width is recomputed whenever an onsomeAttribute or onsomeOtherAttribute event occurred.

So for example

<view name="beatles" width="${this.paul.width + 28}"> 
  <view name="paul" οnclick="clickhandler()" > 
    <!-- clickhandler method here to increase paul's width based on user clicking mouse --> 
  </view> 
</view>

The width of beatles will increase or decrease as a function of paul's width; the expression this.paul.width + 28 is a constraint.

When the user clicks on the paul view, the clickhandler will adjust the size of the paul view. This change will be reported to the ${this.paul.width + 28} constraint, which will then adjust the beatles view to the width of the paul view plus an additional 28 pixels. All of these steps are invisible to the user because they occur instantly.

This, of course is a trivial example, but it serves to make the point that in declaring the structure of your objects in LZX you also declare the rules by which they will relate to each other. Constraints are a fundamental concept in LZX programming, and learning to "think in LZX" is a mostly a matter of learning to properly model your system's behavior in terms of the constraints on its constituent parts. Chapter 27, Constraints covers constraints in depth.

 

4.1. Lexical and View Hierarchies

An LZX application is expressed as a hierarchy of objects, usually visual objects, all of which are contained in a single object called the Canvas. Recall that LZX programs are XML documents, the Canvas is the root element. The simplest LZX program is thus:

<canvas/>

This program compiles and executes, but has no output. As the simplest visual object is the View, a minimal LZX program would look something like:

<canvas>
  <view>
    <text> Hello World!</text> 
  </view> 
</canvas>

This code clearly defines a hierarchy of three objects. We can make their visual relationship more visible by giving the canvas and view sizes and background colors:

In this simple case, the lexical hierarchy in the code corresponds to the visual hierarchy in the canvas. In fact, a <text> object is an instance of a class derived from <view> . The typical LZX program repeats this pattern on a larger scale: the canvas contains views which contain other views, and so forth. Classes are used to replicate view groupings; components such as buttons, windows, input fields and sliders are examples of classes built from views.

LZX affords a variety of ways to simplify the relationships among views. For example, there are several categories of layouts that handle the "housekeeping" of placing views in relationship to each other. These are described in Chapter 17, Layout and Design.

However, the relationship between the textual hierarchy in the code and the visual hierarchy on the canvas is not always as neat as in the example above. In particular, LZX's powerful data binding semantics make it possible for a single <view> tag in the text to cause the creation of an arbitrary number of instances of view objects. In such cases it becomes very important to have a precise way of talking about complex relationships among objects. Chapter 26, Views covers this topic in depth.

 

4.2. Lexical Scope

In LZX the concepts of local and global namespaces, or scopes, are basically the same as in JavaScript. Having said that, it should be pointed out that JavaScript follows rules that are sometimes surprising to Java Programmers.

In JavaScript, all variables are global unless they are preceded by the keyword var.

Thus

a = 7; // defines a global variable a

and

var a = 7 // defines a local variable a

This syntax means, for example, that an assignment in a method definition can set an instance of a global variable:

for (a = 0; a <n; a++);

Creates a global variable named a, or changes the value of this variable if it already exists. What the programmer meant to write was

for (var a = 0; a <n; a++);

In LZX, the name attribute is local and the id attribute is global. Thus

<canvas> 
  <view name="john" id="grandfather"> 
    <view name="john" id="father"> 
      <view name="john" id="son"/> 
    </view> 
  </view> 
</canvas>

is a valid name scheme. The innermost view can be referenced by Canvas.john.john.john or simply son.

As will be discussed below, functions created using the <script> tag can be accessed from anywhere in the program.