summaryrefslogtreecommitdiff
path: root/demos/quickstart/protected/pages/chap2/KeyConcepts.page
blob: 701633c414ecc720eaab275fa045044031bf5d71 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
<com:TContent ID="body" >
<h1>Key Concepts</h1>

<h2>Components</h2>
<p>
A component is an instance of <code>TComponent</code> or its child class. The base class <code>TComponent</code> implements the mechanism of component properties and events.
</p>

<h3>Component Properties</h3>
<p>
A component property can be viewed as a public variable describing a specific aspect of the component, such as the background color, the font size, etc. A property is defined by the existence of a getter and/or a setter method in the component class. For example, in <code>TControl</code>, we have
<pre class="source">
class TControl extends TComponent {
    public function getID() {
        ...
    }
    public function setID($value) {
        ...
    }
}
</pre>
This defines a property named <code>ID</code>. Reading the property (e.g. <code>echo $component-&gt;ID;</code>) is equivalent to invoking the getter method (e.g. <code>echo $component-&gt;getID();</code>); and writing the property (e.g. <code>$component-&gt;ID='Button';</code>) is equivalent to invoking the setter method (e.g. <code>$component-&gt;setID('Button');</code>).
</p>
<p>
A property is read-only if it has a getter method but no setter method. Since PHP method names are case-insensitive, property names are also case-insensitive. A component class inherits all its ancestor classes' properties.
</p>

<h3>Component Events</h3>
<p>
Component events are special properties that take method names as their values. Attaching (setting) a method to an event will hook up the method to the places at which the event is raised. Therefore, the behavior of a component can be modified in a way that may not be foreseen during the development of the component.
</p>
<p>
A component event is defined by the existence of an <code>on</code>-method. For example, in <code>TButton</code>, we have
<pre class="source">
class TButton extends TWebControl {
    public function onClick($param) {
        ...
    }
}
</pre>
This defines an event named <code>Click</code>, and a handler can be attached to the event using one of the following ways,
<pre class="source">
$button-&gt;Click=$callback;
$button-&gt;Click-&gt;add($callback);
$button-&gt;Click[]=$callback;
$button-&gt;attachEventHandler('Click',$callback);
</pre>
where <code>$callback</code> refers to a valid PHP callback (e.g. a function name, a class method <code>array($object,'method')</code>, etc.)
</p>

<h2>Controls</h2>
<p>
A control is an instance of class <code>TControl</code> or its subclass. A control is a component defined in addition with user interface. The base class <code>TControl</code> defines the parent-child relationship among controls which reflects the containment relationship among user interface elements.
</p>

<h3>Parent-Child Relationship</h3>
<p>
A parent control is in charge of the state transition of its child controls. The rendering result of the child controls are usually used to compose the parent control's presentation.
</p>
<p>
The parent-child relationship is usually established by the framework via <a href="?page=chap2.Templates1">templates</a>. In code, you may explicitly specify a control as a child of another using the following method,
<pre class="source">
$parent->Controls->add($child);
</pre>
where the property <code>Controls</code> refers to the child control collection of the parent.
</p>

<h2>Pages</h2>
<p>
Pages are top-most controls that have no parent (you may consider application as their container though). The presentation of pages are directly displayed to end-users.
</p>

</com:TContent>