diff options
Diffstat (limited to 'demos')
| -rw-r--r-- | demos/quickstart/protected/pages/Fundamentals/Controls.page | 38 | ||||
| -rw-r--r-- | demos/quickstart/protected/pages/Fundamentals/Pages.page | 17 | ||||
| -rw-r--r-- | demos/quickstart/protected/pages/Fundamentals/lifecycles.gif | bin | 0 -> 60897 bytes | |||
| -rw-r--r-- | demos/quickstart/protected/pages/Fundamentals/lifecycles.vsd | bin | 0 -> 225280 bytes |
4 files changed, 51 insertions, 4 deletions
diff --git a/demos/quickstart/protected/pages/Fundamentals/Controls.page b/demos/quickstart/protected/pages/Fundamentals/Controls.page index 7703003d..6c45acf1 100644 --- a/demos/quickstart/protected/pages/Fundamentals/Controls.page +++ b/demos/quickstart/protected/pages/Fundamentals/Controls.page @@ -4,16 +4,48 @@ 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>
+<h2>Control Tree</h2>
<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.
+Controls are related to each other via parent-child relationship. Each parent control can have one or several child controls. 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. The parent-child relationship brings together controls into a control tree. A page is at the root of the tree, whose presentation is returned to the end-users.
</p>
<p>
-The parent-child relationship is usually established by the framework via <a href="?page=Configurations.Templates1">templates</a>. In code, you may explicitly specify a control as a child of another using the following method,
+The parent-child relationship is usually established by the framework via <a href="?page=Configurations.Templates1">templates</a>. In code, you may explicitly specify a control as a child of another using one of the following methods,
<pre class="source">
$parent->Controls->add($child);
+$parent->Controls[]=$child;
</pre>
where the property <code>Controls</code> refers to the child control collection of the parent.
</p>
+<h2>Control Identification</h2>
+<p>
+Each control has an <code>ID</code> property that can be uniquely identify itself among its sibling controls. In addition, each control has a <code>UniqueID</code> and a <code>ClientID</code> which can be used to globally identify the control in the tree that the control resides in. <code>UniqueID</code> and <code>ClientID</code> are very similar. The former is used by the framework to determine the location of the corresponding control in the tree, while the latter is mainly used on the client side as HTML tag IDs. In general, you should not rely on the explicit format of <code>UniqueID</code> or <code>ClientID</code>.
+</p>
+
+<h2>Naming Containers</h2>
+<p>
+Each control has a naming container which is a control creating a unique namespace for differentiating between controls with the same <code>ID</code>. For example, a <code>TRepeater</code> control creates multiple items each having child controls with the same <code>ID</code>s. To differentiate these child controls, each item serves as a naming container. Therefore, a child control may be uniquely identified using its naming container's <code>ID</code> together with its own <code>ID</code>. As you may already have understood, <code>UniqueID</code> and <code>ClientID</code> rely on the naming containers.
+</p>
+<p>
+A control can serve as a naming container if it implements the <code>INamingContainer</code> interface.
+</p>
+
+<h2>ViewState and ControlState</h2>
+<p>
+HTTP is a stateless protocol, meaning it does not provide functionality to support continuing interaction between a user and a server. Each request is considered as discrete and independent of each other. A Web application, however, often needs to know what a user has done in previous requests. People thus introduce sessions to help remember such state information.
+</p>
+<p>
+PRADO borrows the viewstate and controlstate concept from Microsoft ASP.NET to provides additional stateful programming mechanism. A value storing in viewstate or controlstate may be available to the next requests if the new requests are form submissions (called postback) to the same page by the same user. The difference between viewstate and controlstate is that the former can be disabled while the latter cannot.
+</p>
+<p>
+Viewstate and controlstate are implemented in <code>TControl</code>. They are commonly used to define various properties of controls. To save and retrieve values from viewstate or controlstate, use following methods,
+<pre class="source">
+$this->getViewState('Name',$defaultValue);
+$this->setViewState('Name',$value,$defaultValue);
+$this->getControlState('Name',$defaultValue);
+$this->setControlState('Name',$value,$defaultValue);
+</pre>
+where <code>$this</code> refers to the control instance, <code>Name</code> refers to a key identifying the persistent value, <code>$defaultValue</code> is optional. When retrieving values from viewstate or controlstate, if the corresponding key does not exist, the default value will be returned.
+</p>
+
</com:TContent>
\ No newline at end of file diff --git a/demos/quickstart/protected/pages/Fundamentals/Pages.page b/demos/quickstart/protected/pages/Fundamentals/Pages.page index 71434ae1..02662558 100644 --- a/demos/quickstart/protected/pages/Fundamentals/Pages.page +++ b/demos/quickstart/protected/pages/Fundamentals/Pages.page @@ -2,7 +2,22 @@ <h1>Pages</h1>
<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.
+Pages are top-most controls that have no parent. The presentation of pages are directly displayed to end-users. Users access pages by sending page service requests.
+</p>
+<p>
+Each page must have a <a href="?page=Configurations.Templates1">template</a> file. The file name suffix must be <code>.page</code>. The file name (without suffix) is the page name. PRADO will try to locate a page class file under the directory containing the page template file. Such a page class file must have the same file name (suffixed with <code>.php</code>) as the template file. If the class file is not found, the page will take class <code>TPage</code>.
+</p>
+
+<h2>PostBack</h2>
+<p>
+A form submission is called <i>postback</i> if the submission is made to the page containing the form. Postback can be considered an event happened on the client side, raised by the user. PRADO will try to identify which control on the server side is responsible for a postback event. If one is determined, for example, a <code>TButton</code>, we call it the postback event sender which will translate the postback event into some specific server-side event (e.g. <code>Click</code> and <code>Command</code> events for <code>TButton</code>).
+
+</p>
+
+<h2>Page Lifecycles</h2>
+<p>
+Understanding the page lifecycles is crucial to grasp PRADO programming. Page lifecycles refer to the state transitions of a page when serving this page to end-users. They can be depicted in the following statechart,
+<img src="<%~lifecycles.gif %>" />
</p>
</com:TContent>
\ No newline at end of file diff --git a/demos/quickstart/protected/pages/Fundamentals/lifecycles.gif b/demos/quickstart/protected/pages/Fundamentals/lifecycles.gif Binary files differnew file mode 100644 index 00000000..5edaff5f --- /dev/null +++ b/demos/quickstart/protected/pages/Fundamentals/lifecycles.gif diff --git a/demos/quickstart/protected/pages/Fundamentals/lifecycles.vsd b/demos/quickstart/protected/pages/Fundamentals/lifecycles.vsd Binary files differnew file mode 100644 index 00000000..368d0ba7 --- /dev/null +++ b/demos/quickstart/protected/pages/Fundamentals/lifecycles.vsd |
