Add "block-content" to allow user comments on block level elements in quickstart docs.

8 files changed, 74 insertions, 75 deletions

diff --git a/demos/quickstart/protected/pages/Fundamentals/Applications.page b/demos/quickstart/protected/pages/Fundamentals/Applications.page
index 48db41e8..8fd22fa2 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Applications.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Applications.page
@@ -1,12 +1,12 @@
 <com:TContent ID="body" >

 

 <h1 id="1201">Applications</h1>

-<p>

+<p id="160157" class="block-content">

 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>

+<p id="160158" class="block-content">

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

-<com:TTextHighlighter CssClass="source">

+<com:TTextHighlighter CssClass="source block-content" id="code_160071">

 require_once('/path/to/prado.php');

 $application = new TApplication;

 $application->run();

@@ -15,11 +15,11 @@ where the method <tt>run()</tt> starts the application to handle user requests.
 </p>

 

 <h2 id="1202">Directory Organization</h2>

-<p>

+<p id="160159" class="block-content">

 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%>" class="figure"/>

 </p>

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

-<ul>

+<ul id="u2" class="block-content">

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

@@ -29,12 +29,12 @@ A minimal PRADO application contains two files: an entry file and a page templat
 <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 id="160160" class="block-content">

 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 id="1203">Application Deployment</h2>

-<p>

+<p id="160161" class="block-content">

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

 </p>

 <ol>

@@ -44,10 +44,10 @@ Deploying a PRADO application mainly involves copying directories. For example,
 </ol>

 

 <h2 id="1204">Application Lifecycles</h2>

-<p>

+<p id="160162" class="block-content">

 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>

+<p id="160163" class="block-content">

 The application lifecycles can be depicted as follows,

 </p>

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

diff --git a/demos/quickstart/protected/pages/Fundamentals/Architecture.page b/demos/quickstart/protected/pages/Fundamentals/Architecture.page
index 5811da71..4fa6434f 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Architecture.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Architecture.page
@@ -1,12 +1,12 @@
 <com:TContent ID="body" >

 <h1 id="601">Architecture</h1>

 

-<p>

+<p id="100111" class="block-content">

 PRADO is primarily a presentational framework, although it is not limited to be so. The framework focuses on making Web programming, which deals most of the time with user interactions, to be component-based and event-driven so that developers can be more productive. The following class tree depicts some of the major classes provided by PRADO,

 </p>

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

 

-<p>

+<p id="100112" class="block-content">

 When a PRADO application is processing a page request, its static object diagram can be shown as follows,

 </p>

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

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

 <h1 id="701">Components</h1>

-<p>

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

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

+<com:TTextHighlighter CssClass="source block-content" id="code_110056">

 class TControl extends TComponent {

     public function getID() {

         ...

@@ -18,34 +18,34 @@ class TControl extends TComponent {
 }

 </com:TTextHighlighter>

 </p>

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

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

+<com:TTextHighlighter CssClass="source block-content" id="code_110058">

 $id = $component->getID();

 $component->setID( $id );

 </com:TTextHighlighter>

 </p>

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

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

+<p id="110118" class="block-content">

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

-<com:TTextHighlighter CssClass="source">

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

+<com:TTextHighlighter CssClass="source block-content" id="code_110060">

 $name = $component->getFont()->getName();

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

 </com:TTextHighlighter>

@@ -54,12 +54,12 @@ $component-&gt;getFont()-&gt;setName( $name );
 </p>

 

 <h2 id="703">Component Events</h2>

-<p>

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

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

+<com:TTextHighlighter CssClass="source block-content" id="code_110061">

 class TButton extends TWebControl {

     public function onClick( $param ) {

         ...

@@ -67,7 +67,7 @@ class TButton extends TWebControl {
 }

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

+<com:TTextHighlighter CssClass="source block-content" id="code_110062">

 $button->OnClick = $callback;

 $button->OnClick->add( $callback );

 $button->OnClick[] = $callback;

@@ -77,40 +77,40 @@ where <tt>$callback</tt> refers to a valid PHP callback (e.g. a function name, a
 </p>

 

 <h2 id="704">Namespaces</h2>

-<p>

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

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

+<p id="110123" class="block-content">

 To use a namespace in code, do as follows,

-<com:TTextHighlighter CssClass="source">

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

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

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

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

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

+<com:TTextHighlighter CssClass="source block-content" id="code_110065">

 $component = new ComponentClassName;

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

 </com:TTextHighlighter>

@@ -118,9 +118,9 @@ where <tt>ComponentType</tt> refers to a class name or a type name in namespace
 </p>

 

 <h3 id="708">Static Component Instantiation</h3>

-<p>

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

+<com:TTextHighlighter Language="prado" CssClass="source block-content" id="code_110066">

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

 </com:TTextHighlighter>

 </p>

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

 <h1 id="801">Controls</h1>

-<p>

+<p id="120128" class="block-content">

 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 id="802">Control Tree</h2>

-<p>

+<p id="120129" class="block-content">

 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>

+<p id="120130" class="block-content">

 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,

-<com:TTextHighlighter CssClass="source">

+<com:TTextHighlighter CssClass="source block-content" id="code_120067">

 $parent->Controls->add($child);

 $parent->Controls[]=$child;

 </com:TTextHighlighter>

@@ -18,28 +18,28 @@ where the property <tt>Controls</tt> refers to the child control collection of t
 </p>

 

 <h2 id="803">Control Identification</h2>

-<p>

+<p id="120131" class="block-content">

 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 id="804">Naming Containers</h2>

-<p>

+<p id="120132" class="block-content">

 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>

+<p id="120133" class="block-content">

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

 </p>

 

 <h2 id="805">ViewState and ControlState</h2>

-<p>

+<p id="120134" class="block-content">

 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>

+<p id="120135" class="block-content">

 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>

+<p id="120136" class="block-content">

 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,

-<com:TTextHighlighter CssClass="source">

+<com:TTextHighlighter CssClass="source block-content" id="code_120068">

 $this->getViewState('Name',$defaultValue);

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

 $this->getControlState('Name',$defaultValue);

diff --git a/demos/quickstart/protected/pages/Fundamentals/Hangman.page b/demos/quickstart/protected/pages/Fundamentals/Hangman.page
index 56180b9e..01a7dc80 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Hangman.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Hangman.page
@@ -1,13 +1,12 @@
 <com:TContent ID="body" >

 

 <h1 id="1301">Sample: Hangman Game</h1>

-<p>

+<p id="60043" class="block-content">

 Having seen the simple "Hello World" application, we now build a more complex application called "Hangman Game". In this game, the player is asked to guess a word, a letter at a time. If he guesses a letter right, the letter will be shown in the word. The player can continue to guess as long as the number of his misses is within a prespecified bound. The player wins the game if he finds out the word within the miss bound, or he loses.

 </p>

-<p>

+<p id="60044" class="block-content">

 To facilitate the building of this game, we show the state transition diagram of the gaming process in the following,

-</p>

-<p>

+<br /><br />

 To be continued...

 </p>

 <com:RunBar PagePath="Fundamentals.Samples.Hangman.Home" />

diff --git a/demos/quickstart/protected/pages/Fundamentals/Modules.page b/demos/quickstart/protected/pages/Fundamentals/Modules.page
index df67f0f3..0ac82016 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Modules.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Modules.page
@@ -1,49 +1,49 @@
 <com:TContent ID="body" >

 

 <h1 id="1001">Modules</h1>

-<p>

+<p id="140141" class="block-content">

 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>

+<p id="140142" class="block-content">

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

 </p>

-<p>

+<p id="140143" class="block-content">

 There are three core modules that are loaded by default whenever an application runs. They are <a href="#request">request module</a>, <a href="#response">response module</a>, and <a href="#error">error handler module</a>. In addition, <a href="#session">session module</a> is loaded when it is used in the application. PRADO provides default implementation for all these modules. <a href="#custom">Custom modules</a> may be configured or developed to override or supplement these core modules.

 </p>

 

 <a name="request"></a>

 <h2 id="1002">Request Module</h2>

-<p>

+<p id="140144" class="block-content">

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

 <h2 id="1003">Response Module</h2>

-<p>

+<p id="140145" class="block-content">

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

 <h2 id="1004">Session Module</h2>

-<p>

+<p id="140146" class="block-content">

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

 <h2 id="1005">Error Handler Module</h2>

-<p>

+<p id="140147" class="block-content">

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

 <h2 id="1006">Custom Modules</h2>

-<p>

+<p id="140148" class="block-content">

 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>

+<p id="140149" class="block-content">

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

 </p>

-<p>

+<p id="140150" class="block-content">

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

 </p>

 

diff --git a/demos/quickstart/protected/pages/Fundamentals/Pages.page b/demos/quickstart/protected/pages/Fundamentals/Pages.page
index 3403bddc..8042ddcd 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Pages.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Pages.page
@@ -1,21 +1,21 @@
 <com:TContent ID="body" >

 

 <h1 id="901">Pages</h1>

-<p>

+<p id="130137" class="block-content">

 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>

+<p id="130138" class="block-content">

 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 id="902">PostBack</h2>

-<p>

+<p id="130139" class="block-content">

 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>OnClick</tt> and <tt>OnCommand</tt> events for <tt>TButton</tt>).

 

 </p>

 

 <h2 id="903">Page Lifecycles</h2>

-<p>

+<p id="130140" class="block-content">

 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>

diff --git a/demos/quickstart/protected/pages/Fundamentals/Services.page b/demos/quickstart/protected/pages/Fundamentals/Services.page
index 920c6bea..803f76e0 100644
--- a/demos/quickstart/protected/pages/Fundamentals/Services.page
+++ b/demos/quickstart/protected/pages/Fundamentals/Services.page
@@ -1,29 +1,29 @@
 <com:TContent ID="body" >

 

 <h1 id="1101">Services</h1>

-<p>

+<p id="150151" class="block-content">

 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>

+<p id="150152" class="block-content">

 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,

-<com:TTextHighlighter Language="none" CssClass="source">

+<com:TTextHighlighter Language="none" CssClass="source block-content" id="code_150069">

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

 </com:TTextHighlighter>

 </p>

-<p>

+<p id="150153" class="block-content">

 Developers may implement additional services for their applications. To make a service available, configure it in <a href="?page=Configurations.AppConfig">application configurations</a>.

 </p>

 

 <h2 id="1102">Page Service</h2>

-<p>

+<p id="150154" class="block-content">

 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>

+<p id="150155" class="block-content">

 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>

+<p id="150156" class="block-content">

 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,

-<com:TTextHighlighter Language="none" CssClass="source">

+<com:TTextHighlighter Language="none" CssClass="source block-content" id="code_150070">

 http://hostname/index.php

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

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