summaryrefslogtreecommitdiff
path: root/demos
diff options
context:
space:
mode:
authorxue <>2005-12-26 00:32:02 +0000
committerxue <>2005-12-26 00:32:02 +0000
commitb5c09ced2f84a18afc11871904bd5706ae0ec3c2 (patch)
tree34c62dae91b6b3474059c91940158d692e764c4c /demos
parentaef9116ba5329eeb24a375b7b914fac84652d29d (diff)
Diffstat (limited to 'demos')
-rw-r--r--demos/quickstart/protected/pages/chap2/Configurations.page82
1 files changed, 82 insertions, 0 deletions
diff --git a/demos/quickstart/protected/pages/chap2/Configurations.page b/demos/quickstart/protected/pages/chap2/Configurations.page
new file mode 100644
index 00000000..75a3d0aa
--- /dev/null
+++ b/demos/quickstart/protected/pages/chap2/Configurations.page
@@ -0,0 +1,82 @@
+<com:TContent ID="body" >
+<h1>Configurations</h1>
+<p>
+PRADO uses configurations to glue together components into pages and applications. There are <a href="#ac">application configurations</a>, <a href="#pfc">page folder configurations</a>, and <a href="?page=chap2.Templates1">templates</a>. Application and page folder configurations are optional if default values are used. Templates are mainly used by pages and template controls. They are optional, too.
+</p>
+<p>
+In this section, we focus on the application and page folder configurations. Templates are detailed in the next few sections.
+</p>
+
+<a name="ac" />
+<h2>Application Configurations</h2>
+<p>
+Application configurations are used to specify the global behavior of an application. This consists of specifying the paths, modules, services and parameters that will be used in an application.
+</p>
+<p>
+Application configurations are stored in an XML file which is passed as a parameter to the <code>TApplication</code> instance. The format of application configurations is shown in the following,
+<pre class="source">
+&lt;application PropertyName="PropertyValue" ...&gt;
+ &lt;paths&gt;
+ &lt;alias id="AliasID" path="AliasPath" /&gt;
+ &lt;using namespace="Namespace" /&gt;
+ &lt;/paths&gt;
+ &lt;modules&gt;
+ &lt;module id="ModuleID" class="ModuleClass" PropertyName="PropertyValue" ... /&gt;
+ &lt;/modules&gt;
+ &lt;services&gt;
+ &lt;service id="ServiceID" class="ServiceClass" PropertyName="PropertyValue" ... /&gt;
+ &lt;/services&gt;
+ &lt;parameters&gt;
+ &lt;parameter id="ParameterID" class="ParameterClass" PropertyName="PropertyValue" ... /&gt;
+ &lt;/parameters&gt;
+&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,
+<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.
+</p>
+
+<a name="pfc" />
+<h2>Page Folder Configurations</h2>
+<p>
+Page folder configurations are mainly used by <code>TPageService</code> to modify or append the application configuration. As the name indicates, a page folder configuration is associated with a directory storing some page files. It is stored as an XML file named <code>config.xml</code>.
+</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.
+</p>
+<p>
+The format of a page folder configuration file is as follows,
+<pre class="source">
+&lt;configuration&gt;
+ &lt;paths&gt;
+ &lt;alias id="AliasID" path="AliasPath" /&gt;
+ &lt;using namespace="Namespace" /&gt;
+ &lt;/paths&gt;
+ &lt;modules&gt;
+ &lt;module id="ModuleID" class="ModuleClass" PropertyName="PropertyValue" ... /&gt;
+ &lt;/modules&gt;
+ &lt;authorization&gt;
+ &lt;allow pages="PageID1,PageID2" users="User1,User2" roles="Role1,Role2" verb="post" /&gt;
+ &lt;deny pages="PageID1,PageID2" users="User1,User2" roles="Role1,Role2" verb="post" /&gt;
+ &lt;/authorization&gt;
+ &lt;pages PropertyName="PropertyValue" ...&gt;
+ &lt;page id="PageID" PropertyName="PropertyValue" ... /&gt;
+ &lt;/pages&gt;
+ &lt;parameters&gt;
+ &lt;parameter id="ParameterID" class="ParameterClass" PropertyName="PropertyValue" ... /&gt;
+ &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.
+</p>
+
+</com:TContent> \ No newline at end of file