14 files changed, 127 insertions, 72 deletions

diff --git a/demos/quickstart/protected/pages/Configurations/AppConfig.page b/demos/quickstart/protected/pages/Configurations/AppConfig.page
index dc4675f1..101e449c 100644
--- a/demos/quickstart/protected/pages/Configurations/AppConfig.page
+++ b/demos/quickstart/protected/pages/Configurations/AppConfig.page
@@ -5,7 +5,7 @@
 Application configurations are used to specify the global behavior of an application. They include specification of path aliases, namespace usages, module and service configurations, and parameters.

 </p>

 <p>

-Configuration for an application is stored in an XML file named <code>application.xml</code>, which should be located under the application base path. Its format is shown in the following,

+Configuration for an application is stored in an XML file named <tt>application.xml</tt>, which should be located under the application base path. Its format is shown in the following,

 <pre class="source">

 &lt;application PropertyName="PropertyValue" ...&gt;

   &lt;paths&gt;

@@ -24,17 +24,17 @@ Configuration for an application is stored in an XML file named <code>applicatio
 &lt;/application&gt;

 </pre>

 <ul>

-<li>The outermost element <code>&lt;application&gt;</code> corresponds to the <code>TApplication</code> instance. The <code>PropertyName="PropertyValue"</code> pairs specify the initial values for the properties of <code>TApplication</code>.</li>

-<li>The <code>&lt;paths&gt;</code> element contains the definition of path aliases and the PHP inclusion paths for the application. Each path alias is specified via an <code>&lt;alias&gt;</code> whose <code>path</code> attribute takes an absolute path or a path relative to the directory containing the application configuration file. The <code>&lt;using&gt;</code> element specifies a particular path (in terms of namespace) to be appended to the PHP include paths when the application runs. PRADO defines two default aliases: <code>System</code> and <code>Application</code>. The former refers to the PRADO framework root directory, and the latter refers to the directory containing the application configuration file.</li>

-<li>The <code>&lt;modules&gt;</code> element contains the configurations for a list of modules. Each module is specified by a <code>&lt;module&gt;</code> element. Each module is uniquely identified by the <code>id</code> attribute and is of type <code>class</code>. The <code>PropertyName="PropertyValue"</code> pairs specify the initial values for the properties of the module.</li>

-<li>The <code>&lt;services&gt;</code> element is similar to the <code>&lt;modules&gt;</code> element. It mainly specifies the services provided by the application.</li>

-<li>The <code>&lt;parameters&gt;</code> element contains a list of application-level parameters that are accessible from anywhere in the application. You may specify component-typed parameters like specifying modules, or you may specify string-typed parameters which take a simpler format as follows,

+<li>The outermost element <tt>&lt;application&gt;</tt> corresponds to the <tt>TApplication</tt> instance. The <tt>PropertyName="PropertyValue"</tt> pairs specify the initial values for the properties of <tt>TApplication</tt>.</li>

+<li>The <tt>&lt;paths&gt;</tt> element contains the definition of path aliases and the PHP inclusion paths for the application. Each path alias is specified via an <tt>&lt;alias&gt;</tt> whose <tt>path</tt> attribute takes an absolute path or a path relative to the directory containing the application configuration file. The <tt>&lt;using&gt;</tt> element specifies a particular path (in terms of namespace) to be appended to the PHP include paths when the application runs. PRADO defines two default aliases: <tt>System</tt> and <tt>Application</tt>. The former refers to the PRADO framework root directory, and the latter refers to the directory containing the application configuration file.</li>

+<li>The <tt>&lt;modules&gt;</tt> element contains the configurations for a list of modules. Each module is specified by a <tt>&lt;module&gt;</tt> element. Each module is uniquely identified by the <tt>id</tt> attribute and is of type <tt>class</tt>. The <tt>PropertyName="PropertyValue"</tt> pairs specify the initial values for the properties of the module.</li>

+<li>The <tt>&lt;services&gt;</tt> element is similar to the <tt>&lt;modules&gt;</tt> element. It mainly specifies the services provided by the application.</li>

+<li>The <tt>&lt;parameters&gt;</tt> element contains a list of application-level parameters that are accessible from anywhere in the application. You may specify component-typed parameters like specifying modules, or you may specify string-typed parameters which take a simpler format as follows,

 <pre class="source">

 &lt;parameter id="ParameterID"&gt;ParameterValue&lt;/parameter&gt;

 </pre>

 </li>

 </ul>

-By default without explicit configuration, a PRADO application when running will load a few core modules, such as <code>THttpRequest</code>, <code>THttpResponse</code>, etc. It will also provide the <code>TPageService</code> as a default service. Configuration and usage of these modules and services are covered in individual sections of this tutorial. Note, if your application takes default settings for these modules and service, you do not need to provide an application configuration. However, if these modules or services are not sufficient, or you want to change their behavior by configuring their property values, you will need an application configuration.

+By default without explicit configuration, a PRADO application when running will load a few core modules, such as <tt>THttpRequest</tt>, <tt>THttpResponse</tt>, etc. It will also provide the <tt>TPageService</tt> as a default service. Configuration and usage of these modules and services are covered in individual sections of this tutorial. Note, if your application takes default settings for these modules and service, you do not need to provide an application configuration. However, if these modules or services are not sufficient, or you want to change their behavior by configuring their property values, you will need an application configuration.

 </p>

 

 </com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Configurations/PageConfig.page b/demos/quickstart/protected/pages/Configurations/PageConfig.page
index e6a6afaf..a7d0ef8e 100644
--- a/demos/quickstart/protected/pages/Configurations/PageConfig.page
+++ b/demos/quickstart/protected/pages/Configurations/PageConfig.page
@@ -2,10 +2,10 @@
 

 <h1>Page Configurations</h1>

 <p>

-Page configurations are mainly used by <code>TPageService</code> to modify or append the application configuration. As the name indicates, a page configuration is associated with a directory storing some page files. It is stored as an XML file named <code>config.xml</code>.

+Page configurations are mainly used by <tt>TPageService</tt> to modify or append the application configuration. As the name indicates, a page configuration is associated with a directory storing some page files. It is stored as an XML file named <tt>config.xml</tt>.

 </p>

 <p>

-When a user requests a page stored under <code>&lt;BasePath&gt;/dir1/dir2</code>, the <code>TPageService</code> will try to parse and load <code>config.xml</code> files under <code>&lt;BasePath&gt;/dir1</code> and <code>&lt;BasePath&gt;/dir1/dir2</code>. Paths, modules, and parameters specified in these configuration files will be appended or merged into the existing application configuration.

+When a user requests a page stored under <tt>&lt;BasePath&gt;/dir1/dir2</tt>, the <tt>TPageService</tt> will try to parse and load <tt>config.xml</tt> files under <tt>&lt;BasePath&gt;/dir1</tt> and <tt>&lt;BasePath&gt;/dir1/dir2</tt>. Paths, modules, and parameters specified in these configuration files will be appended or merged into the existing application configuration.

 </p>

 <p>

 The format of a page configuration file is as follows,

@@ -30,7 +30,7 @@ The format of a page configuration file is as follows,
   &lt;/parameters&gt;

 &lt;/configuration&gt;

 </pre>

-The <code>&lt;paths&gt;</code>, <code>&lt;modules&gt;</code> and <code>&lt;parameters&gt;</code> are similar to those in an application configuration. The <code>&lt;authorization&gt;</code> specifies the authorization rules that apply to the current page directory and all its subdirectories. It will be explained in more detail in future sections. The <code>&lt;pages&gt;</code> element specifies the initial values for the properties of pages. Each <code>&lt;page&gt;</code> element specifies the initial property values for a particular page identified by the <code>id</code attribute. Initial property values given in the <code>&lt;pages&gt;</code> element apply to all pages in the current directory and all its subdirectories.

+The <tt>&lt;paths&gt;</tt>, <tt>&lt;modules&gt;</tt> and <tt>&lt;parameters&gt;</tt> are similar to those in an application configuration. The <tt>&lt;authorization&gt;</tt> specifies the authorization rules that apply to the current page directory and all its subdirectories. It will be explained in more detail in future sections. The <tt>&lt;pages&gt;</tt> element specifies the initial values for the properties of pages. Each <tt>&lt;page&gt;</tt> element specifies the initial property values for a particular page identified by the <tt>id</code attribute. Initial property values given in the <tt>&lt;pages&gt;</tt> element apply to all pages in the current directory and all its subdirectories.

 </p>

 

 </com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Configurations/Templates1.page b/demos/quickstart/protected/pages/Configurations/Templates1.page
index c406cfad..5d387e14 100644
--- a/demos/quickstart/protected/pages/Configurations/Templates1.page
+++ b/demos/quickstart/protected/pages/Configurations/Templates1.page
@@ -1,7 +1,7 @@
 <com:TContent ID="body" >

 <h1>Templates: Part I</h1>

 <p>

-Templates are used to specify the presentational layout of controls. A template can contain static text, components, or controls that contribute to the ultimate presentation of the associated control. By default, an instance of <code>TTemplateControl</code> or its subclass may automatically load a template from a file whose name is the same as the control class name. For page templates, the file name suffix must be <code>.page</code>; for other regular template controls, the suffix is <code>.tpl</code>.

+Templates are used to specify the presentational layout of controls. A template can contain static text, components, or controls that contribute to the ultimate presentation of the associated control. By default, an instance of <tt>TTemplateControl</tt> or its subclass may automatically load a template from a file whose name is the same as the control class name. For page templates, the file name suffix must be <tt>.page</tt>; for other regular template controls, the suffix is <tt>.tpl</tt>.

 </p>

 <p>The template format is like HTML, with a few PRADO-specifc tags, including <a href="#ct">component tags</a>, <a href="#tct">template control tags</a>, <a href="#cot">comment tags</a>, <a href="?page=Configurations.Templates2#dct">dynamic content tags</a>, and <a href="?page=Configurations.Templates3#dpt">dynamic property tags</a>. .

 </p>

@@ -18,10 +18,10 @@ The format of a component tag is as follows,
 body content

 &lt;/com:ComponentType&gt;

 </pre>

-<code>ComponentType</code> can be either the class name or the dotted type name (e.g. <code>System.Web.UI.TControl</code>) of the component. <code>PropertyName</code> and <code>EventName</code> are both case-insensitive. <code>PropertyName</code> can be a property or subproperty name (e.g. <code>Font.Name</code>). Note, <code>PropertyValue</code> will be HTML-decoded when assigned to the corresponding property. Content enclosed between the opening and closing component tag are normally treated the body of the component.

+<tt>ComponentType</tt> can be either the class name or the dotted type name (e.g. <tt>System.Web.UI.TControl</tt>) of the component. <tt>PropertyName</tt> and <tt>EventName</tt> are both case-insensitive. <tt>PropertyName</tt> can be a property or subproperty name (e.g. <tt>Font.Name</tt>). Note, <tt>PropertyValue</tt> will be HTML-decoded when assigned to the corresponding property. Content enclosed between the opening and closing component tag are normally treated the body of the component.

 </p>

 <p>

-It is required that component tags nest properly with each other and an opening component tag be paired with a closing tag, similar to that in XML. The following shows a component tag specifying the <code>Text</code> property and <code>Click</code> event of a button control,

+It is required that component tags nest properly with each other and an opening component tag be paired with a closing tag, similar to that in XML. The following shows a component tag specifying the <tt>Text</tt> property and <tt>Click</tt> event of a button control,

 <pre class="source">

 &lt;com:TButton Text="Register" Click="registerUser" />

 </pre>

@@ -33,7 +33,7 @@ To deal conveniently with properties taking take big trunk of initial data, the
 PropertyValue

 &lt;/prop:PropertyName&gt;

 </pre>

-It is equivalent to <code>...PropertyName="PropertyValue"...</code> in a component tag. Property initialization tags must be directly enclosed between the corresponding opening and closing component tag.

+It is equivalent to <tt>...PropertyName="PropertyValue"...</tt> in a component tag. Property initialization tags must be directly enclosed between the corresponding opening and closing component tag.

 </p>

 

 <a name="tct" />

@@ -42,10 +42,10 @@ A template control tag is used to configure the initial property values of the c
 <pre class="source">

 &lt;%@ PropertyName="PropertyValue" ... %&gt;

 </pre>

-Like in component tags, <code>PropertyName</code> is case-insensitive and can be a property or subproperty name.

+Like in component tags, <tt>PropertyName</tt> is case-insensitive and can be a property or subproperty name.

 </p>

 <p>

-Initial values specified via the template control tag are assigned to the corresponding properties when the template control is being constructed. Therefore, you may override these property values in a later stage, such as the <code>Init</code> stage of the control.

+Initial values specified via the template control tag are assigned to the corresponding properties when the template control is being constructed. Therefore, you may override these property values in a later stage, such as the <tt>Init</tt> stage of the control.

 </p>

 <p>

 Template control tag is optional in a template. Each template can contain at most one template control tag. You can place the template control tag anywhere in the template. It is recommended that you place it at the beginning of the template for better visibility.

diff --git a/demos/quickstart/protected/pages/Configurations/Templates2.page b/demos/quickstart/protected/pages/Configurations/Templates2.page
index b7eaaf7a..c4528a0b 100644
--- a/demos/quickstart/protected/pages/Configurations/Templates2.page
+++ b/demos/quickstart/protected/pages/Configurations/Templates2.page
@@ -14,7 +14,7 @@ An expression tag represents a PHP expression that is evaluated when the templat
 <pre class="source">

 &lt;%= PhpExpression %&gt;

 </pre>

-Inernally, an expression tag is represented by a <code>TExpression</code> control. Therefore, in the expression <code>$this</code> refers to the <code>TExpression</code> control. For example, the following expression tag will display the current page title at the place,

+Inernally, an expression tag is represented by a <tt>TExpression</tt> control. Therefore, in the expression <tt>$this</tt> refers to the <tt>TExpression</tt> control. For example, the following expression tag will display the current page title at the place,

 <pre class="source">

 &lt;%= $this-&gt;Page-&gt;Title %&gt;

 </pre>

@@ -23,7 +23,7 @@ Inernally, an expression tag is represented by a <code>TExpression</code> contro
 <a name="st" />

 <h3>Statement Tags</h3>

 <p>

-Statement tags are similar to expression tags, except that statement tags contain PHP statements rather than expressions. The output of the PHP statements (using for example <code>echo</code> or <code>print</code> in PHP) are displayed at the place where the statement tag resides in the template. Inernally, a statement tag is represented by a <code>TStatements</code> control. Therefore, in the statements <code>$this</code> refers to the <code>TStatements</code> control. The format of statement tags is as follows,

+Statement tags are similar to expression tags, except that statement tags contain PHP statements rather than expressions. The output of the PHP statements (using for example <tt>echo</tt> or <tt>print</tt> in PHP) are displayed at the place where the statement tag resides in the template. Inernally, a statement tag is represented by a <tt>TStatements</tt> control. Therefore, in the statements <tt>$this</tt> refers to the <tt>TStatements</tt> control. The format of statement tags is as follows,

 <pre class="source">

 &lt;%%

 PHP Statements

@@ -43,7 +43,7 @@ echo strftime("%A %e %B %Y",time());
 <a name="dt" />

 <h3>Databind Tags</h3>

 <p>

-Databind tags are similar to expression tags, except that the expressions are evaluated only when a <code>dataBind()</code> call is invoked on the controls representing the databind tags. Internally, a <code>TLiteral</code> control is used to represent a databind tag and <code>$this</code> in the expression would refer to the control. The format of databind tags is as follows,

+Databind tags are similar to expression tags, except that the expressions are evaluated only when a <tt>dataBind()</tt> call is invoked on the controls representing the databind tags. Internally, a <tt>TLiteral</tt> control is used to represent a databind tag and <tt>$this</tt> in the expression would refer to the control. The format of databind tags is as follows,

 <pre class="source">

 &lt;%# PhpExpression %&gt;

 </pre>

@@ -69,7 +69,7 @@ The format of asset tags is as follows,
 <pre class="source">

 &lt;%~ LocalFileName %&gt;

 </pre>

-where <code>LocalFileName</code> refers to a file path that is relative to the directory containing the current template file. The file path can be a single file or a directory. If the latter, the content in the whole directory will be made accessible by end-users.

+where <tt>LocalFileName</tt> refers to a file path that is relative to the directory containing the current template file. The file path can be a single file or a directory. If the latter, the content in the whole directory will be made accessible by end-users.

 </p>

 <p>

 BE VERY CAUTIOUS when you are using asset tags as it may expose to end-users files that you probably do not want them to see.

diff --git a/demos/quickstart/protected/pages/Configurations/Templates3.page b/demos/quickstart/protected/pages/Configurations/Templates3.page
index 328687fb..7ab55281 100644
--- a/demos/quickstart/protected/pages/Configurations/Templates3.page
+++ b/demos/quickstart/protected/pages/Configurations/Templates3.page
@@ -10,7 +10,7 @@ Dynamic property tags are very similar to dynamic content tags, except that they
 body content

 &lt;/com:ComponentType&gt;

 </pre>

-where you may enclose <code>DynamicPropertyTag</code> within single or double quotes for better readability.

+where you may enclose <tt>DynamicPropertyTag</tt> within single or double quotes for better readability.

 </p>

 <p>

 We now introduce the available types of dynamic property tags that may be used in the above. Like dynamic content tags, we have <a href="#et">expression tags</a>, <a href="#dt">databind tags</a>, <a href="#pt">parameter tags</a> and <a href="#at">asset tags</a>. (Note, there is no statement tag here.)

@@ -23,7 +23,7 @@ An expression tag represents a PHP expression that is evaluated when the templat
 <pre class="source">

 &lt;%= PhpExpression %&gt;

 </pre>

-In the expression, <code>$this</code> refers to the component specified by the component tag. The following example specifies a <code>TLabel</code> control whose <code>Text</code> property is initialized as the current page title when the <code>TLabel</code> control is being constructed,

+In the expression, <tt>$this</tt> refers to the component specified by the component tag. The following example specifies a <tt>TLabel</tt> control whose <tt>Text</tt> property is initialized as the current page title when the <tt>TLabel</tt> control is being constructed,

 <pre class="source">

 &lt;com:TLabel Text=&lt;%= $this-&gt;Page-&gt;Title %&gt; /&gt;

 </pre>

@@ -35,7 +35,7 @@ Note, unlike dynamic content tags, the expressions tags for component properties
 <a name="dt" />

 <h3>Databind Tags</h3>

 <p>

-Databind tags are similar to expression tags, except that the expressions are evaluated only when a <code>dataBind()</code> call is invoked on the controls represented by the component tags. In the expression, <code>$this</code> refers to the control itself. Databind tags do not apply to all components. They can only be used for controls.

+Databind tags are similar to expression tags, except that the expressions are evaluated only when a <tt>dataBind()</tt> call is invoked on the controls represented by the component tags. In the expression, <tt>$this</tt> refers to the control itself. Databind tags do not apply to all components. They can only be used for controls.

 </p>

 <p>

 The format of databind tags is as follows,

@@ -64,7 +64,7 @@ The format of asset tags is as follows,
 <pre class="source">

 &lt;%~ LocalFileName %&gt;

 </pre>

-where <code>LocalFileName</code> refers to a file path that is relative to the directory containing the current template file. The file path can be a single file or a directory. If the latter, the content in the whole directory will be made accessible by end-users.

+where <tt>LocalFileName</tt> refers to a file path that is relative to the directory containing the current template file. The file path can be a single file or a directory. If the latter, the content in the whole directory will be made accessible by end-users.

 </p>

 <p>

 BE VERY CAUTIOUS when you are using asset tags as it may expose to end-users files that you probably do not want them to see.

diff --git a/demos/quickstart/protected/pages/Controls/Overview.page b/demos/quickstart/protected/pages/Controls/Overview.page
index 7c3fbea6..da16d170 100644
--- a/demos/quickstart/protected/pages/Controls/Overview.page
+++ b/demos/quickstart/protected/pages/Controls/Overview.page
@@ -1,7 +1,7 @@
 <com:TContent ID="body" >

 <h1>Controls Overview</h1>

 <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.

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

 </p>

 <p>

 Control classes constitute one of the major part of PRADO framework. Nearly every generic HTML element can find its representation in terms of a PRADO control. Mastering these controls becomes extremely important to effectively and efficiently compose applications using PRADO.

diff --git a/demos/quickstart/protected/pages/Fundamentals/Applications.page b/demos/quickstart/protected/pages/Fundamentals/Applications.page
index c64a9ea4..8ea9a1f7 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Applications.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Applications.page
@@ -2,7 +2,7 @@
 

 <h1>Applications</h1>

 <p>

-An application is an instance of <code>TApplication</code> or its derived class. It manages modules that provide different functionalities and are loaded when needed. It provides services to end-users. It is the central place to store various parameters used in an application. In a PRADO application, the application instance is the only object that is globally accessible via <code>Prado::getApplication()</code> function call.

+An application is an instance of <tt>TApplication</tt> or its derived class. It manages modules that provide different functionalities and are loaded when needed. It provides services to end-users. It is the central place to store various parameters used in an application. In a PRADO application, the application instance is the only object that is globally accessible via <tt>Prado::getApplication()</tt> function call.

 </p>

 <p>

 Applications are configured via <a href="?page=Configurations.AppConfig">application configurations</a>. They are usually created entry scripts like the following,

@@ -11,7 +11,7 @@ require_once('/path/to/prado.php');
 $application = new TApplication;

 $application-&gt;run();

 </pre>

-where the method <code>run()</code> starts the application to handle user requests.

+where the method <tt>run()</tt> starts the application to handle user requests.

 </p>

 

 <h2>Directory Organization</h2>

@@ -19,32 +19,32 @@ where the method <code>run()</code> starts the application to handle user reques
 A minimal PRADO application contains two files: an entry file and a page template file. They must be organized as follows,

 <img src="<%~directory.gif%>" />

 <ul>

-<li><code>wwwroot</code> - Web document root or sub-directory.</li>

-<li><code>index.php</code> - entry script of the PRADO application.</li>

-<li><code>assets</code> - directory storing published private files. See <a href="?page=Advanced.Assets">assets</a> section.</li>

-<li><code>protected</code> - application base path storing application data and private script files. This directory should be configured inaccessible to Web-inaccessible, or it may be located outside of Web directories.</li>

-<li><code>runtime</code> - application runtime storage path. This directory is used by PRADO to store application runtime information, such as application state, cached data, etc.</li>

-<li><code>pages</code> - base path storing all PRADO pages. See <a href="?page=Fundamentals.Services">services</a> section.</li>

-<li><code>Home.page</code> - default page returned when users do not explicitly specify the page requested. This is a page template file. The file name without suffix is the page name. The page class is <code>TPage</code>. If there is also a class file <code>Home.php</code>, the page class becomes <code>Home</code>.</li>

+<li><tt>wwwroot</tt> - Web document root or sub-directory.</li>

+<li><tt>index.php</tt> - entry script of the PRADO application.</li>

+<li><tt>assets</tt> - directory storing published private files. See <a href="?page=Advanced.Assets">assets</a> section.</li>

+<li><tt>protected</tt> - application base path storing application data and private script files. This directory should be configured inaccessible to Web-inaccessible, or it may be located outside of Web directories.</li>

+<li><tt>runtime</tt> - application runtime storage path. This directory is used by PRADO to store application runtime information, such as application state, cached data, etc.</li>

+<li><tt>pages</tt> - base path storing all PRADO pages. See <a href="?page=Fundamentals.Services">services</a> section.</li>

+<li><tt>Home.page</tt> - default page returned when users do not explicitly specify the page requested. This is a page template file. The file name without suffix is the page name. The page class is <tt>TPage</tt>. If there is also a class file <tt>Home.php</tt>, the page class becomes <tt>Home</tt>.</li>

 </ul>

 </p>

 <p>

-A product PRADO application usually needs more files. It may include an application configuration file named <code>application.xml</code> under the application base path <code>protected</code>. The pages may be organized in directories, some of which may contain page configuration files named <code>config.xml</code>. Fore more details, please see <a href="?page=Configurations.Overview">configurations</a> section.

+A product PRADO application usually needs more files. It may include an application configuration file named <tt>application.xml</tt> under the application base path <tt>protected</tt>. The pages may be organized in directories, some of which may contain page configuration files named <tt>config.xml</tt>. Fore more details, please see <a href="?page=Configurations.Overview">configurations</a> section.

 </p>

 

 <h2>Application Deployment</h2>

 <p>

 Deploying a PRADO application mainly involves copying directories. For example, to deploy the above minimal application to another server, follow the following steps,

 <ol>

-<li>Copy the content under <code>wwwroot</code> to a Web-accessible directory on the new server.</li>

-<li>Modify the entry script file <code>index.php</code> so that it includes correctly the <code>prado.php</code> file.</li>

-<li>Remove all content under <code>assets</code> and <code>runtime</code> directories and make sure both directories are writable by the Web server process.</li>

+<li>Copy the content under <tt>wwwroot</tt> to a Web-accessible directory on the new server.</li>

+<li>Modify the entry script file <tt>index.php</tt> so that it includes correctly the <tt>prado.php</tt> file.</li>

+<li>Remove all content under <tt>assets</tt> and <tt>runtime</tt> directories and make sure both directories are writable by the Web server process.</li>

 </ol>

 </p>

 

 <h2>Application Lifecycles</h2>

 <p>

-Like page lifecycles, an application also has lifecycles. Application modules can register for the lifecycle events. When the application reaches a particular lifecycle and raises the corresponding event, the registered module methods are invoked automatically. Modules included in the PRADO release, such as <code>TAuthManager</code>, are using this way to accomplish their goals.

+Like page lifecycles, an application also has lifecycles. Application modules can register for the lifecycle events. When the application reaches a particular lifecycle and raises the corresponding event, the registered module methods are invoked automatically. Modules included in the PRADO release, such as <tt>TAuthManager</tt>, are using this way to accomplish their goals.

 </p>

 <p>

 The application lifecycles can be depicted as follows,

diff --git a/demos/quickstart/protected/pages/Fundamentals/Components.page b/demos/quickstart/protected/pages/Fundamentals/Components.page
index b49c16e5..20888fba 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Components.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Components.page
@@ -1,12 +1,12 @@
 <com:TContent ID="body" >

 <h1>Components</h1>

 <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.

+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>Component Properties</h2>

 <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

+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,

 <pre class="source">

 class TControl extends TComponent {

     public function getID() {

@@ -17,18 +17,47 @@ class TControl extends TComponent {
     }

 }

 </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>

+To get or set the <tt>ID</tt> property, do as follows, just like working with a variable,

+<pre class="source">

+$id = $component-&gt;ID;

+$component-&gt;ID = $id;

+</pre>

+This is equivalent to the following,

+<pre class="source">

+$id = $component-&gt;getID();

+$component-&gt;setID( $id );

+</pre>

 </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>Subproperties</h3>

+<p>

+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>

+To get or set the <tt>Name</tt> subproperty, use the following method,

+<pre class="source">

+$name = $component-&gt;getSubProperty('Font.Name');

+$component-&gt;setSubProperty('Font.Name', $name);

+</pre>

+This is equivalent to the following,

+<pre class="source">

+$name = $component-&gt;getFont()-&gt;getName();

+$component-&gt;getFont()-&gt;setName( $name );

+</pre>

+

+</p>

+

 <h2>Component Events</h2>

 <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

+A component event is defined by the existence of an <tt>on</tt>-method. For example, in <tt>TButton</tt>, we have

 <pre class="source">

 class TButton extends TWebControl {

     public function onClick($param) {

@@ -36,14 +65,40 @@ class TButton extends TWebControl {
     }

 }

 </pre>

-This defines an event named <code>Click</code>, and a handler can be attached to the event using one of the following ways,

+This defines an event named <tt>Click</tt>, 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.)

+where <tt>$callback</tt> refers to a valid PHP callback (e.g. a function name, a class method <tt>array($object,'method')</tt>, etc.)

+</p>

+

+<h2>Namespaces</h2>

+<p>

+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>

+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,

+<pre class="source">

+PathAlias.Dir1.Dir2

+</pre>

+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>

+To use a namespace in code, do as follows,

+<pre class="source">

+Prado::using('PathAlias.Dir1.Dir2.*');

+</pre>

+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

+<pre class="source">

+Prado::using('PathAlias.Dir1.Dir2.MyClass');

+</pre>

+which will include the class file if <tt>MyClass</tt> is not defined.

+</p>

+<p>

+For more details about defining path aliases, see <a href="?page=Configurations.AppConfig">application configuration</a> section.

 </p>

 

 <h2>Component Instantiation</h2>

@@ -58,12 +113,12 @@ Dynamic component instantiation means creating component instances in PHP code.
 $component = new ComponentClassName;

 $component = Prado::createComponent('ComponentType');

 </pre>

-where <code>ComponentType</code> refers to a class name or a dot-connected type name (e.g. <code>System.Web.UI.TControl</code>). The second approach is introduced to compensate for the lack of namespace support in PHP.

+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>Static Component Instantiation</h3>

 <p>

-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 <code>TButton</code> component on the page,

+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,

 <pre class="source">

 &lt;com:TButton Text="Register" /&gt;

 </pre>

diff --git a/demos/quickstart/protected/pages/Fundamentals/Controls.page b/demos/quickstart/protected/pages/Fundamentals/Controls.page
index 6c45acf1..cc0b3eda 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Controls.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Controls.page
@@ -1,7 +1,7 @@
 <com:TContent ID="body" >

 <h1>Controls</h1>

 <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.

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

 </p>

 

 <h2>Control Tree</h2>

@@ -14,20 +14,20 @@ The parent-child relationship is usually established by the framework via <a hre
 $parent->Controls->add($child);

 $parent->Controls[]=$child;

 </pre>

-where the property <code>Controls</code> refers to the child control collection of the parent.

+where the property <tt>Controls</tt> 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>.

+Each control has an <tt>ID</tt> property that can be uniquely identify itself among its sibling controls. In addition, each control has a <tt>UniqueID</tt> and a <tt>ClientID</tt> which can be used to globally identify the control in the tree that the control resides in. <tt>UniqueID</tt> and <tt>ClientID</tt> 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 <tt>UniqueID</tt> or <tt>ClientID</tt>.

 </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.

+Each control has a naming container which is a control creating a unique namespace for differentiating between controls with the same <tt>ID</tt>. For example, a <tt>TRepeater</tt> control creates multiple items each having child controls with the same <tt>ID</tt>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 <tt>ID</tt> together with its own <tt>ID</tt>. As you may already have understood, <tt>UniqueID</tt> and <tt>ClientID</tt> rely on the naming containers.

 </p>

 <p>

-A control can serve as a naming container if it implements the <code>INamingContainer</code> interface.

+A control can serve as a naming container if it implements the <tt>INamingContainer</tt> interface.

 </p>

 

 <h2>ViewState and ControlState</h2>

@@ -38,14 +38,14 @@ HTTP is a stateless protocol, meaning it does not provide functionality to suppo
 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,

+Viewstate and controlstate are implemented in <tt>TControl</tt>. 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-&gt;getViewState('Name',$defaultValue);

 $this-&gt;setViewState('Name',$value,$defaultValue);

 $this-&gt;getControlState('Name',$defaultValue);

 $this-&gt;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.

+where <tt>$this</tt> refers to the control instance, <tt>Name</tt> refers to a key identifying the persistent value, <tt>$defaultValue</tt> 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/Modules.page b/demos/quickstart/protected/pages/Fundamentals/Modules.page
index b8472e90..3fe190fe 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Modules.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Modules.page
@@ -2,7 +2,7 @@
 

 <h1>Modules</h1>

 <p>

-A module is an instance of a class implementing the <code>IModule</code> interface. A module is commonly designed to provide specific functionality that may be plugged into a PRADO application and shared by all components in the application.

+A module is an instance of a class implementing the <tt>IModule</tt> interface. A module is commonly designed to provide specific functionality that may be plugged into a PRADO application and shared by all components in the application.

 </p>

 <p>

 PRADO uses configurations to specify whether to load a module, load what kind of modules, and how to initialize the loaded modules. Developers may replace the core modules with their own implementations via application configuration, or they may write new modules to provide additional functionalities. For example, a module may be developed to provide common database logic for one or several pages. For more details, please see the <a href="?page=Configurations.Overview">configurations</a>.

@@ -14,34 +14,34 @@ There are three core modules that are loaded by default whenever an application
 <a name="request" />

 <h2>Request Module</h2>

 <p>

-Request module represents provides storage and access scheme for user request sent via HTTP. User request data comes from several sources, including URL, post data, session data, cookie data, etc. These data can all be accessed via the request module. By default, PRADO uses <code>THttpRequest</code> as request module. The request module can be accessed via the <code>Request</code> property of application and controls.

+Request module represents provides storage and access scheme for user request sent via HTTP. User request data comes from several sources, including URL, post data, session data, cookie data, etc. These data can all be accessed via the request module. By default, PRADO uses <tt>THttpRequest</tt> as request module. The request module can be accessed via the <tt>Request</tt> property of application and controls.

 </p>

 

 <a name="response" />

 <h2>Response Module</h2>

 <p>

-Response module implements the mechanism for sending output to client users. Response module may be configured to control how output are cached on the client side. It may also be used to send cookies back to the client side. By default, PRADO uses <code>THttpResponse</code> as response module. The response module can be accessed via the <code>Response</code> property of application and controls.

+Response module implements the mechanism for sending output to client users. Response module may be configured to control how output are cached on the client side. It may also be used to send cookies back to the client side. By default, PRADO uses <tt>THttpResponse</tt> as response module. The response module can be accessed via the <tt>Response</tt> property of application and controls.

 </p>

 

 <a name="session" />

 <h2>Session Module</h2>

 <p>

-Session module encapsulates the functionalities related with user session handling. Session module is automatically loaded when an application uses session. By default, PRADO uses <code>THttpSession</code> as session module, which is a simple wrapper of the session functions provided by PHP. The session module can be accessed via the <code>Session</code> property of application and controls.

+Session module encapsulates the functionalities related with user session handling. Session module is automatically loaded when an application uses session. By default, PRADO uses <tt>THttpSession</tt> as session module, which is a simple wrapper of the session functions provided by PHP. The session module can be accessed via the <tt>Session</tt> property of application and controls.

 </p>

 

 <a name="error" />

 <h2>Error Handler Module</h2>

 <p>

-Error handler module is used to capture and process all error conditions in an application. PRADO uses <code>TErrorHandler</code> as error handler module. It captures all PHP warnings, notices and exceptions, and displays in an appropriate form to end-users. The error handler module can be accessed via the <code>ErrorHandler</code> property of the application instance.

+Error handler module is used to capture and process all error conditions in an application. PRADO uses <tt>TErrorHandler</tt> as error handler module. It captures all PHP warnings, notices and exceptions, and displays in an appropriate form to end-users. The error handler module can be accessed via the <tt>ErrorHandler</tt> property of the application instance.

 </p>

 

 <a name="custom" />

 <h2>Custom Modules</h2>

 <p>

-PRADO is released with a few more modules besides the core ones. They include caching modules (<code>TSqliteCache</code> and <code>TMemCache</code>), user management module (<code>TUserManager</code>), authentication and authorization module (<code>TAuthManager</code>), etc.

+PRADO is released with a few more modules besides the core ones. They include caching modules (<tt>TSqliteCache</tt> and <tt>TMemCache</tt>), user management module (<tt>TUserManager</tt>), authentication and authorization module (<tt>TAuthManager</tt>), etc.

 </p>

 <p>

-When <code>TPageService</code> is requested, it also loads modules specific for page service, including asset manager (<code>TAssetManager</code>), template manager (<code>TTemplateManager</code>), theme/skin manager (<code>TThemeManager</code>), and page state persister (<code>TPageStatePersister</code>).

+When <tt>TPageService</tt> is requested, it also loads modules specific for page service, including asset manager (<tt>TAssetManager</tt>), template manager (<tt>TTemplateManager</tt>), theme/skin manager (<tt>TThemeManager</tt>), and page state persister (<tt>TPageStatePersister</tt>).

 </p>

 <p>

 Custom modules and core modules are all configurable via <a href="?page=Configurations.Overview">configurations</a>.

diff --git a/demos/quickstart/protected/pages/Fundamentals/Pages.page b/demos/quickstart/protected/pages/Fundamentals/Pages.page
index 02662558..8dfb5caa 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Pages.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Pages.page
@@ -5,12 +5,12 @@
 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>.

+Each page must have a <a href="?page=Configurations.Templates1">template</a> file. The file name suffix must be <tt>.page</tt>. 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 <tt>.php</tt>) as the template file. If the class file is not found, the page will take class <tt>TPage</tt>.

 </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>).

+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 <tt>TButton</tt>, we call it the postback event sender which will translate the postback event into some specific server-side event (e.g. <tt>Click</tt> and <tt>Command</tt> events for <tt>TButton</tt>).

 

 </p>

 

diff --git a/demos/quickstart/protected/pages/Fundamentals/Services.page b/demos/quickstart/protected/pages/Fundamentals/Services.page
index 0cd7762c..49b8041b 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Services.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Services.page
@@ -2,10 +2,10 @@
 

 <h1>Services</h1>

 <p>

-A service is an instance of a class implementing the <code>IService</code> interface. Each kind of service processes a specific type of user requests. For example, the page service responds to users' requests for PRADO pages.

+A service is an instance of a class implementing the <tt>IService</tt> interface. Each kind of service processes a specific type of user requests. For example, the page service responds to users' requests for PRADO pages.

 </p>

 <p>

-A service is uniquely identified by its <code>ID</code> property. By default when <code>THttpRequest</code> is used as the <a href="?page=Fundamentals.Modules#request">request module</a>, GET variable names are used to identify which service a user is requesting. If a GET variable name is equal to some service <code>ID</code>, the request is considered for that service, and the value of the GET variable is passed as the service parameter. For page service, the name of the GET variable must be <code>page</code>. For example, the following URL requests for the <code>Fundamentals.Services</code> page,

+A service is uniquely identified by its <tt>ID</tt> property. By default when <tt>THttpRequest</tt> is used as the <a href="?page=Fundamentals.Modules#request">request module</a>, GET variable names are used to identify which service a user is requesting. If a GET variable name is equal to some service <tt>ID</tt>, the request is considered for that service, and the value of the GET variable is passed as the service parameter. For page service, the name of the GET variable must be <tt>page</tt>. For example, the following URL requests for the <tt>Fundamentals.Services</tt> page,

 <pre class="source">

 http://hostname/index.php?page=Fundamentals.Services

 </pre>

@@ -16,19 +16,19 @@ Developers may implement additional services for their applications. To make a s
 

 <h2>Page Service</h2>

 <p>

-PRADO implements <code>TPageService</code> to process users' page requests. Pages are stored under a directory specified by the <code>BasePath</code> property of the page service. The property defaults to <code>pages</code> directory under the application base path. You may change this default by configuring the service in the application configuration.

+PRADO implements <tt>TPageService</tt> to process users' page requests. Pages are stored under a directory specified by the <tt>BasePath</tt> property of the page service. The property defaults to <tt>pages</tt> directory under the application base path. You may change this default by configuring the service in the application configuration.

 </p>

 <p>

-Pages may be organized into subdirectories under the <code>BasePath</code>. In each directory, there may be a page configuration file named <code>config.xml</code>, which contains configurations effective only when a page under that directory or a sub-directory is requested. For more details, see the <a href="?page=Configurations.PageConfig">page configuration</a> section.

+Pages may be organized into subdirectories under the <tt>BasePath</tt>. In each directory, there may be a page configuration file named <tt>config.xml</tt>, which contains configurations effective only when a page under that directory or a sub-directory is requested. For more details, see the <a href="?page=Configurations.PageConfig">page configuration</a> section.

 </p>

 <p>

-Service parameter for the page service refers to the page being requested. A parameter like <code>Fundamentals.Services</code> refers to the <code>Services</code> page under the <code>&lt;BasePath&gt;/Fundamentals</code> directory. If such a parameter is absent in a request, a default page named <code>Home</code> is assumed. Using <code>THttpRequest</code> as the request module (default), the following URLs will request for <code>Home</code>, <code>About</code> and <code>Register</code> pages, respectively,

+Service parameter for the page service refers to the page being requested. A parameter like <tt>Fundamentals.Services</tt> refers to the <tt>Services</tt> page under the <tt>&lt;BasePath&gt;/Fundamentals</tt> directory. If such a parameter is absent in a request, a default page named <tt>Home</tt> is assumed. Using <tt>THttpRequest</tt> as the request module (default), the following URLs will request for <tt>Home</tt>, <tt>About</tt> and <tt>Register</tt> pages, respectively,

 <pre class="source">

 http://hostname/index.php

 http://hostname/index.php?page=About

 http://hostname/index.php?page=Users.Register

 </pre>

-where the first example takes advantage of the fact that the page service is the default service and <code>Home</code> is the default page.

+where the first example takes advantage of the fact that the page service is the default service and <tt>Home</tt> is the default page.

 </p>

 

 </com:TContent>
\ No newline at end of file
diff --git a/demos/quickstart/protected/pages/Samples/HelloWorld.page b/demos/quickstart/protected/pages/Samples/HelloWorld.page
index 87169697..7f7e8538 100644
--- a/demos/quickstart/protected/pages/Samples/HelloWorld.page
+++ b/demos/quickstart/protected/pages/Samples/HelloWorld.page
@@ -11,7 +11,7 @@ PRADO promotes component-based and event-driven Web programming. The button is r
 </p>

 <img src="<%~HelloWorld/sequence.gif%>" />

 <p>

-The code that a developer needs to write is merely the following event handler function, where <code>$sender</code> refers to the button object.

+The code that a developer needs to write is merely the following event handler function, where <tt>$sender</tt> refers to the button object.

 </p>

 <pre class="source">

 public function buttonClicked($sender,$param)

diff --git a/demos/quickstart/themes/Simple/style.css b/demos/quickstart/themes/Simple/style.css
index 9b7ae2b2..1e2b880b 100644
--- a/demos/quickstart/themes/Simple/style.css
+++ b/demos/quickstart/themes/Simple/style.css
@@ -136,7 +136,7 @@ h3 {
 	padding:10px;

 }

 

-code {

+tt {

 	font-family: "Courier New", Courier, mono;

-	color: #408040;

+	border-bottom: 1px dotted silver;

 }
\ No newline at end of file