diff options
author | ctrlaltca <> | 2013-02-08 16:49:58 +0000 |
---|---|---|
committer | ctrlaltca <> | 2013-02-08 16:49:58 +0000 |
commit | 0f34cca749fade963acd014aff526067b00bc49e (patch) | |
tree | 91cd48dbcff32aad4cb75cbd4dee8017b1912375 /demos/quickstart/protected/pages/Configurations/AppConfig.page | |
parent | 6b390ff3a048b93e1a5feab758cdab7bfdc9b3d1 (diff) |
merged to trunk/ all the changes from branch/3.2 up to r3270
Diffstat (limited to 'demos/quickstart/protected/pages/Configurations/AppConfig.page')
-rw-r--r-- | demos/quickstart/protected/pages/Configurations/AppConfig.page | 57 |
1 files changed, 57 insertions, 0 deletions
diff --git a/demos/quickstart/protected/pages/Configurations/AppConfig.page b/demos/quickstart/protected/pages/Configurations/AppConfig.page index 83f1bc7e..7887d959 100644 --- a/demos/quickstart/protected/pages/Configurations/AppConfig.page +++ b/demos/quickstart/protected/pages/Configurations/AppConfig.page @@ -56,4 +56,61 @@ An external configuration file has the same format as described above. Although By default without explicit configuration, a PRADO application 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:SinceVersion Version="3.2.2" />
+<p class="block-content">
+By default PRADO instanciates all modules defined in the application configuration at the beginning of the application lifecycle. This can hit the application performance if you have a lot of modules defined but not used at every request.
+Since version 3.2.2 you can set the <tt>lazy</tt> property on modules defined in the application configuration to enable the lazy loading of that module.
+
+<com:TTextHighlighter Language="xml" CssClass="source block-content">
+ <modules>
+ <module id="ModuleID" class="ModuleClass" lazy="true" PropertyName="PropertyValue" ... />
+ </modules>
+</com:TTextHighlighter>
+
+A module with the <tt>lazy</tt> property set won't be instanciated until the first time it gets actually used by the application:
+
+<com:TTextHighlighter Language="php" CssClass="source block-content">
+ // requesting the lazy module to the application will instanciate it
+ Prado::getApplication()->getModule('ModuleID');
+</com:TTextHighlighter>
+</p>
+
+<com:SinceVersion Version="3.2" />
+<p class="block-content">
+Since version 3.2 the application configuration can be stored in PHP array format in a file named <tt>application.php</tt>.
+The format of the configuration file is exactly the same of its XML counterpart, but following the PHP syntax.
+</p>
+
+<com:TTextHighlighter Language="php" CssClass="source block-content">
+<?php
+return array(
+ 'application' => array(
+ 'PropertyName' => 'PropertyValue'
+ ),
+ 'modules' => array(
+ 'ModuleID' => array(
+ 'class' => 'ModuleClass',
+ 'properties' => array(
+ 'PropertyName' => 'PropertyValue'
+ ),
+ ),
+ ),
+ 'services' => array(
+ 'ServiceID' => array(
+ 'class' => 'ServiceClass',
+ 'properties' => array(
+ 'PropertyName' => 'PropertyValue'
+ ),
+ ),
+ ),
+);
+</com:TTextHighlighter>
+
+The use of a PHP application configuration must be defined in the <tt>TApplication</tt> constructor, tipically located in the <tt>index.php</tt> entry script:
+
+<com:TTextHighlighter Language="php" CssClass="source block-content">
+$application=new TApplication('protected',false,TApplication::CONFIG_TYPE_PHP);
+$application->run();
+</com:TTextHighlighter>
+
</com:TContent>
|