1 files changed, 20 insertions, 11 deletions
diff --git a/demos/quickstart/protected/pages/GettingStarted/Upgrading.page b/demos/quickstart/protected/pages/GettingStarted/Upgrading.page
index cb89cb10..287d3f84 100644
--- a/demos/quickstart/protected/pages/GettingStarted/Upgrading.page
+++ b/demos/quickstart/protected/pages/GettingStarted/Upgrading.page
@@ -1,8 +1,7 @@
 <com:TContent ID="body" >
 
-<h1>Upgrading from Earlier Versions</h1>
+<h1>Upgrading from v2.x and v1.x</h1>
 
-<h2>Upgrading from v2.x and v1.x</h2>
 <p>
 PRADO v3.0 is NOT backward compatible with earlier versions of PRADO.
 </p>
@@ -10,30 +9,40 @@ PRADO v3.0 is NOT backward compatible with earlier versions of PRADO.
 A good news is, properties and events of most controls remain intact, and the syntax of control templates remains largely unchanged. Therefore, developers' knowledge of earlier versions of PRADO are still applicable in v3.0.
 </p>
 <p>
-We summarize in the following the most significant changes in v3.0 to help developers upgrade their v2.x and v1.x PRADO applications more easily.
+We summarize in the following the most significant changes in v3.0 to help developers upgrade their v2.x and v1.x PRADO applications more easily, if needed.
 </p>
 
-<h3>Component Definition</h3>
+<h2>Component Definition</h2>
 <p>
-Version 3.0 has completely discarded the need of component specification files. It relies more on conventions for defining component properties and events. In particular, a property is defined by the existence of a getter method and/or a setter method, while an event is defined by the existence of an <tt>on</tt>-method. Property and event names in v3.0 are both case-insensitive.
+Version 3.0 has completely discarded the need of component specification files. It relies more on conventions for defining component properties and events. In particular, a property is defined by the existence of a getter method and/or a setter method, while an event is defined by the existence of an <tt>on</tt>-method. Property and event names in v3.0 are both case-insensitive. As a consequence, developers are now required to take care of type conversions when a component property is being set. For example, the following code is used to define the setter method for the <tt>Enabled</tt> property of <tt>TControl</tt>, which is of <tt>boolean</tt> type,
+</p>
+<com:TTextHighlighter Language="php" CssClass="source">
+public function setEnabled($value)
+{
+	$value=TPropertyValue::ensureBoolean($value);
+	$this->setViewState('Enabled',$value,true);
+}
+</com:TTextHighlighter>
+<p>
+where <tt>TPropertyValue::ensureBoolean()</tt> is used to ensure that the input value be a boolean. This is because when the property is configured in template, a string value is passed to the setter. In previous versions, PRADO knows the property type based on the component specification files and does the type conversion for you.
 </p>
 
-<h3>Application Controller</h3>
+<h2>Application Controller</h2>
 <p>
 Application controller now implements a modular architecture. Modules can be plugged in and configured in application specifications. Each module assumes a particular functionality, and they are coordinated together by the <a href="?page=Fundamentals.Applications">application lifecycle</a>. The concept of v2.x modules is replaced in v3.0 by <a href="?page=Configurations.PageConfig">page directories</a>. As a result, the format of v3.0 <a href="?page=Configurations.AppConfig">application specification</a> is also different from earlier versions.
 </p>
 
-<h3>Pages</h3>
+<h2>Pages</h2>
 <p>
-Pages in v3.0 are organized in directories which may be compared to the module concept in v2.x. Pages are requested using the path to them. For example, a URL <tt>index.php?page=Controls.Samples.Sample1</tt> would request for a page named <tt>Sample1</tt> stored under the <tt>[BasePath]/Controls/Samples</tt> directory, where <tt>[BasePath]</tt> refers to the root page path. The file name of a page template must be ended with <tt>.page</tt>, mainly to differentiate from templates of non-page controls whose file names must be ended with <tt>.tpl</tt>.
+Pages in v3.0 are organized in directories which may be compared to the module concept in v2.x. Pages are requested using the path to them. For example, a URL <tt>index.php?page=Controls.Samples.Sample1</tt> would be used to request for a page named <tt>Sample1</tt> stored under the <tt>[BasePath]/Controls/Samples</tt> directory, where <tt>[BasePath]</tt> refers to the root page path. The file name of a page template must be ended with <tt>.page</tt>, mainly to differentiate page templates from non-page control templates whose file names must be ended with <tt>.tpl</tt>.
 </p>
 
-<h3>Control Relationship</h3>
+<h2>Control Relationship</h2>
 <p>
 Version 3.0 redefines the relationships between controls. In particular, the parent-child relationship now refers to the enclosure relationship between controls' presentation. And a new naming-container relationship is introduced to help better manage control IDs. For more details, see the <a href="?page=Fundamentals.Controls">controls</a> section.
 </p>
 
-<h3>Template Syntax</h3>
+<h2>Template Syntax</h2>
 <p>
 The syntax of control templates in v3.0 remains similar to those in earlier versions, with many enhancements. A major change is about the databinding expression. In v3.0, this is done by the following,
 </p>
@@ -44,7 +53,7 @@ The syntax of control templates in v3.0 remains similar to those in earlier vers
 Expression and statement tags are also changed similarly. For more details, see the <a href="?page=Configurations.Templates1">template definition</a> section.
 </p>
 
-<h3>Theme Syntax</h3>
+<h2>Theme Syntax</h2>
 <p>
 Themes in v3.0 are defined like control templates with a few restrictions.
 </p>