summaryrefslogtreecommitdiff
path: root/demos/quickstart/protected/pages/Fundamentals/Components.page
blob: 84c6070ce78469af1bc96912eca8d0e38e37378c (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
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
<com:TContent ID="body" >
<h1 id="701">Components</h1>
<p id="110113" class="block-content">
A component is an instance of <tt>TComponent</tt> or its child class. The base class <tt>TComponent</tt> implements the mechanism of component properties and events.
</p>

<h2 id="702">Component Properties</h2>
<p id="110114" class="block-content">
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 <tt>TControl</tt>, we define its <tt>ID</tt> property using the following getter and setter methods,
<com:TTextHighlighter CssClass="source block-content" id="code_110056">
class TControl extends TComponent {
    public function getID() {
        ...
    }
    public function setID($value) {
        ...
    }
}
</com:TTextHighlighter>
</p>
<p id="110115" class="block-content">
To get or set the <tt>ID</tt> property, do as follows, just like working with a variable,
<com:TTextHighlighter CssClass="source block-content" id="code_110057">
$id = $component->ID;
$component->ID = $id;
</com:TTextHighlighter>
This is equivalent to the following,
<com:TTextHighlighter CssClass="source block-content" id="code_110058">
$id = $component->getID();
$component->setID( $id );
</com:TTextHighlighter>
</p>
<p id="110116" class="block-content">
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 id="706">Subproperties</h3>
<p id="110117" class="block-content">
A subproperty is a property of some object-typed property. For example, <tt>TWebControl</tt> has a <tt>Font</tt> property which is of <tt>TFont</tt> type. Then the <tt>Name</tt> property of <tt>Font</tt> is referred to as a subproperty (with respect to <tt>TWebControl</tt>).
</p>
<p id="110118" class="block-content">
To get or set the <tt>Name</tt> subproperty, use the following method,
<com:TTextHighlighter CssClass="source block-content" id="code_110059">
$name = $component-&gt;getSubProperty('Font.Name');
$component->setSubProperty('Font.Name', $name);
</com:TTextHighlighter>
This is equivalent to the following,
<com:TTextHighlighter CssClass="source block-content" id="code_110060">
$name = $component->getFont()->getName();
$component-&gt;getFont()-&gt;setName( $name );
</com:TTextHighlighter>
</p>

<h3 id="26001">Js-friendly properties</h3>
<p class="block-content">
A JavaScript-friendly property is a property that can accept both simple strings and raw javascript.
Prado automatically encodes all properties sent clientside inside javascript blocks to avoid security problems (like injections or cross site scripting).
If a property is known to always contain only safe javascript code and its value needs to bypass this encoding, that property can be defined in a special way that will make Prado mark its value as "safe".
Js-friendly properties are identified by their name starting with 'js' (case insensitive):
<com:TTextHighlighter CssClass="source block-content">
// getter, defines a readable property 'Text'
function getJsText() { … }
// setter, defines a writable property 'Text', with $value being the value to be set to the property
function setJsText(TJavaScriptLiteral $value) { … }
</com:TTextHighlighter>
Js-friendly properties can be accessed using both their Js-less name and their Js-enabled name:
<com:TTextHighlighter CssClass="source block-content">
// set some simple text as property value 
$component-&gt;Text = 'text';
// set some javascript code as property value
$component-&gt;JsText = 'raw javascript';
</com:TTextHighlighter>
In the first case, the property value will automatically gets encoded when sent clientside inside a javascript block.
In the second case, the property will be 'marked' as being a safe javascript statement and will not be encoded when rendered inside a javascript block.
This special handling makes use of the <tt>TJavaScriptLiteral</tt> class. 
</p>


<h2 id="703">Component Events</h2>
<p id="110119" class="block-content">
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 id="110120" class="block-content">
A component event is defined by the existence of a method whose name starts with the word <tt>on</tt>. The event name is the method name and is thus case-insensitve. For example, in <tt>TButton</tt>, we have
<com:TTextHighlighter CssClass="source block-content" id="code_110061">
class TButton extends TWebControl {
    public function onClick( $param ) {
        ...
    }
}
</com:TTextHighlighter>
This defines an event named <tt>OnClick</tt>, and a handler can be attached to the event using one of the following ways,
<com:TTextHighlighter CssClass="source block-content" id="code_110062">
$button->OnClick = $callback;
$button->OnClick->add( $callback );
$button->OnClick[] = $callback;
$button->attachEventHandler( 'OnClick' , $callback );
</com:TTextHighlighter>
</p>
 The variable <tt>$callback</tt> contains the definition of the event handler that can be either a string referring to a global function name, or an array whose first element refers to an object and second element a method name/path that is reachable by the object, e.g.
 </p>
<ul>
<li>'buttonClicked' : buttonClicked($sender,$param);</li>
<li>array($object,'buttonClicked') : $object->buttonClicked($sender,$param);</li>
<li>array($object,'MainContent.SubmitButton.buttonClicked') : $object->MainContent->SubmitButton->buttonClicked($sender,$param);</li>
</ul>
<com:SinceVersion Version="3.2.3" />
<h2>Global events</h2>
<p>
With the addition of behaviors, a more expansive event model is needed.  There 
are two new event types (global and dynamic events) as well as a more comprehensive 
behavior model that includes class wide behaviors.
</p>
<p>
A global event is defined by all events whose name starts with 'fx'.
The event name is potentially a method name and is thus case-insensitive. All 'fx' events 
are valid as the whole 'fx' event/method space is global in nature. Any object may patch into
any global event by defining that event as a method. Global events have priorities 
just like 'on' events; so as to be able to order the event execution. Due to the 
nature of all events which start with 'fx' being valid, in effect, every object 
has every 'fx' global event. It is simply an issue of tapping into the desired 
global event.
</p>
<p>
A global event that starts with 'fx' can be called even if the object does not
implement the method of the global event.  A call to a non-existing 'fx' method
will, at minimal, function and return null.  If a method argument list has a first 
parameter, it will be returned instead of null.  This allows filtering and chaining.
'fx' methods do not automatically install and uninstall. To install and uninstall an
object's global event listeners, call the object's <tt>listen</tt> and 
<tt>unlisten</tt> methods, respectively.  An object may auto-install its global event
during <tt>__construct</tt> by overriding <tt>getAutoGlobalListen</tt> and returning true.
</p>
<p>
As of PHP version 5.3, nulled objects without code references will still continue to persist
in the global event queue because <tt>__destruct</tt> is not automatically called.  In the common
__destruct method, if an object is listening to global events, then <tt>unlisten</tt> is called.
<tt>unlisten</tt> is required to be manually called before an object is
left without references if it is currently listening to any global events. This includes 
class wide behaviors.
</p>
<p>
An object that contains a method that starts with 'fx' will have those functions 
automatically receive those events of the same name after <tt>listen</tt> is called on the object.
</p>
<p>
An object may listen to a global event without defining an 'fx' method of the same name by 
adding an object method to the global event list.  For example
</p>
<com:TTextHighlighter CssClass="source block-content">
$component->fxGlobalCheck=$callback;  // or $component->OnClick->add($callback);
$component->attachEventHandler('fxGlobalCheck',array($object, 'someMethod'));
</com:TTextHighlighter>
<h2>Events between Objects and their behaviors, Dynamic Events</h2>
<p>
An intra-object/behavior event is defined by methods that start with 'dy'.  Just as with 
'fx' global events, every object has every dynamic event.  Any call to a method that
starts with 'dy' will be handled, regardless of whether it is implemented.  These 
events are for communicating with attached behaviors.
</p>
<p>
Dynamic events can be used in a variety of ways.  They can be used to tell behaviors
when a non-behavior method is called.  Dynamic events could be used as data filters.
They could also be used to specify when a piece of code is to be run, eg. should the 
loop process be performed on a particular piece of data.  In this way, some control
is handed to the behaviors over the process and/or data.
</p>
<p>
If there are no handlers for an 'fx' or 'dy' event, it will return the first
parameter of the argument list.  If there are no arguments, these events
will return null.  If there are handlers an 'fx' method will be called directly
within the object.  Global 'fx' events are triggered by calling <tt>raiseEvent</tt>.
For dynamic events where there are behaviors that respond to the dynamic events, a 
<tt>TCallChain</tt> is developed.  A call chain allows the behavior dynamic event
implementations to call further implementing behaviors within a chain.
</p>
<p>
If an object implements <tt>IDynamicMethods</tt>, all global and object dynamic 
events will be sent to <tt>__dycall</tt>.  In the case of global events, all 
global events will trigger this method.  In the case of behaviors, all undefined
dynamic events  which are called will be passed through to this method.
</p>
<p>
<h2>Behaviors</h2>
<p>
There are two types of behaviors.  There are individual object behaviors and
there are class wide behaviors.  Class behaviors depend upon object behaviors.
</p>
<p>
When a new class implements <tt>IBehavior</tt> or <tt>IClassBehavior</tt> or
extends <tt>TBehavior</tt> or <tt>TClassBehavior</tt>, it may be added to an 
object by calling the object's <tt>attachBehavior</tt>.  The behaviors associated
name can then be used to <tt>enableBehavior</tt> or <tt>disableBehavior</tt> 
the specific behavior.
</p>
<p>
All behaviors may be turned on and off via <tt>enableBehaviors</tt> and 
<tt>disableBehaviors</tt>, respectively.  To check if behaviors are on or off
a call to <tt>getBehaviorsEnabled</tt> will provide the variable.
</p>
<p>
Attaching and detaching whole sets of behaviors is done using 
<tt>attachBehaviors</tt> and <tt>detachBehaviors</tt>.  <tt>clearBehaviors</tt>
removes all of an object's behaviors.
</p>
<p>
<tt>asa</tt> returns a behavior of a specific name.  <tt>isa</tt> is the
behavior inclusive function that acts as the PHP operator <tt>instanceof</tt>.
A behavior could provide the functionality of a specific class thus causing
the host object to act similarly to a completely different class.  A behavior 
would then implement <tt>IInstanceCheck</tt> to provide the identity of the 
different class.
</p>
<p>
Class behaviors are similar to object behaviors except that the class behavior 
is the implementation for all instances of the class.  A class behavior
will have the object upon which is being called be prepended to the parameter
list.  This way the object is known across the class behavior implementation.
</p>
<p>
Class behaviors are attached using <tt>attachClassBehavior</tt> and detached
using <tt>detachClassBehavior</tt>.  Class behaviors are important in that
they will be applied to all new instances of a particular class.  In this way
class behaviors become default behaviors to a new instances of a class in
<tt>__construct</tt>.  Detaching a class behavior will remove the behavior 
from the default set of behaviors created for an object when the object
is instanced.
</p>
<p>
Class behaviors are also added to all existing instances via the global 'fx' 
event mechanism.  When a new class behavior is added, the event 
<tt>fxAttachClassBehavior</tt> is raised and all existing instances that are
listening to this global event (primarily after <tt>listen</tt> is called)
will have this new behavior attached.  A similar process is used when
detaching class behaviors.  Any objects listening to the global 'fx' event
<tt>fxDetachClassBehavior</tt> will have a class behavior removed.
</p>
<h2>Dynamic Intra-Object Events</h2>
<p>
Dynamic events start with 'dy'.  This mechanism is used to allow objects
to communicate with their behaviors directly.  The entire 'dy' event space
is valid.  All attached, enabled behaviors that implement a dynamic event 
are called when the host object calls the dynamic event.  If there is no 
implementation or behaviors, this returns null when no parameters are
supplied and will return the first parameter when there is at least one
parameter in the dynamic event.
</p>
<com:TTextHighlighter CssClass="source block-content">
	null == $this->dyBehaviorEvent();
	5 == $this->dyBehaviorEvent(5); //when no behaviors implement this dynamic event
</com:TTextHighlighter>
<p>
Dynamic events can be chained together within behaviors to allow for data 
filtering. Dynamic events are implemented within behaviors by defining the
event as a method.
</p>
<com:TTextHighlighter CssClass="source block-content">
class TObjectBehavior extends TBehavior {
    public function dyBehaviorEvent($param1, $callchain) {
			//Do something, eg:  $param1 += 13;
			return $callchain->dyBehaviorEvent($param1);
    }
}
</com:TTextHighlighter>
<p>
This implementation of a behavior and dynamic event will flow through to the 
next behavior implementing the dynamic event.  The first parameter is always 
return when it is supplied.  Otherwise a dynamic event returns null.
</p>
<p>
In the case of a class behavior, the object is also prepended to the dynamic
event.
</p>
<com:TTextHighlighter CssClass="source block-content">
class TObjectClassBehavior extends TClassBehavior {
    public function dyBehaviorEvent($hostobject, $param1, $callchain) {
			//Do something, eg:  $param1 += $hostobject->getNumber();
			return $callchain->dyBehaviorEvent($param1);
    }
}
</com:TTextHighlighter>
</p>
<p>
When calling a dynamic event, only the parameters are passed.  The host object
and the call chain are built into the framework.
</p>

<h2>Global Event and Dynamic event catching</h2>

<p>
Given that all global 'fx' events and dynamic 'dy' events are valid and 
operational, there is a mechanism for catching events called that are not
implemented (similar to the built-in PHP method <tt>__call</tt>).  When
a dynamic or global event is called but a behavior does not implement it, 
yet desires to know when an undefined dynamic event is run, the behavior 
implements the interface <tt>IDynamicMethods</tt> and method <tt>__dycall</tt>.
</p>
<p>
In the case of dynamic events, <tt>__dycall</tt> is supplied with the method 
name and its parameters.  When a global event is raised, via <tt>raiseEvent</tt>,
the method is the event name and the parameters are supplied.
</p>
<p>
When implemented, this catch-all mechanism is called for event global event event
when implemented outside of a behavior.  Within a behavior, it will also be called
when the object to which the behavior is attached calls any unimplemented dynamic 
event.  This is the fall-back mechanism for informing a class and/or behavior 
of when an global and/or undefined dynamic event is executed.
</p>

<h2 id="704">Namespaces</h2>
<p id="110121" class="block-content">
A namespace refers to a logical grouping of some class names so that they can be differentiated from other class names even if their names are the same. Since PHP does not support namespace intrinsically, you cannot create instances of two classes who have the same name but with different definitions. To differentiate from user defined classes, all PRADO classes are prefixed with a letter 'T' (meaning 'Type'). Users are advised not to name their classes like this. Instead, they may prefix their class names with any other letter(s).
</p>
<p id="110122" class="block-content">
A namespace in PRADO is considered as a directory containing one or several class files. A class may be specified without ambiguity using such a namespace followed by the class name. Each namespace in PRADO is specified in the following format,
<div class="source">
PathAlias.Dir1.Dir2
</div>
where <tt>PathAlias</tt> is an alias of some directory, while <tt>Dir1</tt> and <tt>Dir2</tt> are subdirectories under that directory. A class named <tt>MyClass</tt> defined under <tt>Dir2</tt> may now be fully qualified as <tt>PathAlias.Dir1.Dir2.MyClass</tt>.
</p>
<p id="110123" class="block-content">
To use a namespace in code, do as follows,
<com:TTextHighlighter CssClass="source block-content" id="code_110063">
Prado::using('PathAlias.Dir1.Dir2.*');
</com:TTextHighlighter>
which appends the directory referred to by <tt>PathAlias.Dir1.Dir2</tt> into PHP include path so that classes defined under that directory may be instantiated without the namespace prefix. You may also include an individual class definition by
<com:TTextHighlighter CssClass="source block-content" id="code_110064">
Prado::using('PathAlias.Dir1.Dir2.MyClass');
</com:TTextHighlighter>
which will include the class file if <tt>MyClass</tt> is not defined.
</p>
<p id="110124" class="block-content">
For more details about defining path aliases, see <a href="?page=Configurations.AppConfig">application configuration</a> section.
</p>

<h2 id="705">Component Instantiation</h2>
<p id="110125" class="block-content">
Component instantiation means creating instances of component classes. There are two types of component instantation: static instantiation and dynamic instantiation. The created components are called static components and dynamic components, respectively.
</p>

<h3 id="707">Dynamic Component Instantiation</h3>
<p id="110126" class="block-content">
Dynamic component instantiation means creating component instances in PHP code. It is the same as the commonly referred object creation in PHP. A component can be dynamically created using one of the following two methods in PHP,
<com:TTextHighlighter CssClass="source block-content" id="code_110065">
$component = new ComponentClassName;
$component = Prado::createComponent('ComponentType');
</com:TTextHighlighter>
where <tt>ComponentType</tt> refers to a class name or a type name in namespace format (e.g. <tt>System.Web.UI.TControl</tt>). The second approach is introduced to compensate for the lack of namespace support in PHP.
</p>

<h3 id="708">Static Component Instantiation</h3>
<p id="110127" class="block-content">
Static component instantiation is about creating components via <a href="?page=Configurations.Overview">configurations</a>. The actual creation work is done by the PRADO framework. For example, in an <a href="?page=Configurations.AppConfig">application configuration</a>, one can configure a module to be loaded when the application runs. The module is thus a static component created by the framework. Static component instantiation is more commonly used in <a href="?page=Configurations.Templates1">templates</a>. Every component tag in a template specifies a component that will be automatically created by the framework when the template is loaded. For example, in a page template, the following tag will lead to the creation of a <tt>TButton</tt> component on the page,
<com:TTextHighlighter Language="prado" CssClass="source block-content" id="code_110066">
&lt;com:TButton Text="Register" /&gt;
</com:TTextHighlighter>
</p>

</com:TContent>