-An application is an instance of TApplication 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 Prado::getApplication() function call.
+An application is an instance of TApplication 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 Prado::getApplication() function call.
Applications are configured via application configurations. They are usually created entry scripts like the following,
@@ -11,7 +11,7 @@ require_once('/path/to/prado.php');
$application = new TApplication;
$application->run();
-where the method run() starts the application to handle user requests.
+where the method run() starts the application to handle user requests.
run() 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,
wwwroot - Web document root or sub-directory.index.php - entry script of the PRADO application.assets - directory storing published private files. See assets section.protected - 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.runtime - application runtime storage path. This directory is used by PRADO to store application runtime information, such as application state, cached data, etc.pages - base path storing all PRADO pages. See services section.Home.page - 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 TPage. If there is also a class file Home.php, the page class becomes Home.
-A product PRADO application usually needs more files. It may include an application configuration file named application.xml under the application base path protected. The pages may be organized in directories, some of which may contain page configuration files named config.xml. Fore more details, please see configurations section.
+A product PRADO application usually needs more files. It may include an application configuration file named application.xml under the application base path protected. The pages may be organized in directories, some of which may contain page configuration files named config.xml. Fore more details, please see configurations section.
Deploying a PRADO application mainly involves copying directories. For example, to deploy the above minimal application to another server, follow the following steps,
wwwroot to a Web-accessible directory on the new server.index.php so that it includes correctly the prado.php file.assets and runtime directories and make sure both directories are writable by the Web server process.
-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 TAuthManager, 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 TAuthManager, are using this way to accomplish their goals.
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 @@
-A component is an instance of
-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 Components
TComponent or its child class. The base class TComponent implements the mechanism of component properties and events.
+A component is an instance of TComponent or its child class. The base class TComponent implements the mechanism of component properties and events.
Component Properties
TControl, 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 TControl, we define its ID property using the following getter and setter methods,
class TControl extends TComponent {
public function getID() {
@@ -17,18 +17,47 @@ class TControl extends TComponent {
}
}
-This defines a property named ID. Reading the property (e.g. echo $component->ID;) is equivalent to invoking the getter method (e.g. echo $component->getID();); and writing the property (e.g. $component->ID='Button';) is equivalent to invoking the setter method (e.g. $component->setID('Button');).
+
+To get or set the ID property, do as follows, just like working with a variable, +
+$id = $component->ID; +$component->ID = $id; ++This is equivalent to the following, +
+$id = $component->getID(); +$component->setID( $id ); +
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.
++A subproperty is a property of some object-typed property. For example, TWebControl has a Font property which is of TFont type. Then the Name property of Font is referred to as a subproperty (with respect to TWebControl). +
++To get or set the Name subproperty, use the following method, +
+$name = $component->getSubProperty('Font.Name');
+$component->setSubProperty('Font.Name', $name);
+
+This is equivalent to the following,
++$name = $component->getFont()->getName(); +$component->getFont()->setName( $name ); ++ + +
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.
-A component event is defined by the existence of an on-method. For example, in TButton, we have
+A component event is defined by the existence of an on-method. For example, in TButton, we have
class TButton extends TWebControl {
public function onClick($param) {
@@ -36,14 +65,40 @@ class TButton extends TWebControl {
}
}
-This defines an event named Click, and a handler can be attached to the event using one of the following ways,
+This defines an event named Click, and a handler can be attached to the event using one of the following ways,
$button->Click=$callback;
$button->Click->add($callback);
$button->Click[]=$callback;
$button->attachEventHandler('Click',$callback);
-where $callback refers to a valid PHP callback (e.g. a function name, a class method array($object,'method'), etc.)
+where $callback refers to a valid PHP callback (e.g. a function name, a class method array($object,'method'), etc.)
+
+
++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). +
++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, +
+PathAlias.Dir1.Dir2 ++where PathAlias is an alias of some directory, while Dir1 and Dir2 are subdirectories under that directory. A class named MyClass defined under Dir2 may now be fully qualified as PathAlias.Dir1.Dir2.MyClass. + +
+To use a namespace in code, do as follows, +
+Prado::using('PathAlias.Dir1.Dir2.*');
+
+which appends the directory referred to by PathAlias.Dir1.Dir2 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
+
+Prado::using('PathAlias.Dir1.Dir2.MyClass');
+
+which will include the class file if MyClass is not defined.
+
++For more details about defining path aliases, see application configuration section.
ComponentType refers to a class name or a dot-connected type name (e.g. System.Web.UI.TControl). The second approach is introduced to compensate for the lack of namespace support in PHP.
+where ComponentType refers to a class name or a type name in namespace format (e.g. System.Web.UI.TControl). The second approach is introduced to compensate for the lack of namespace support in PHP.
-Static component instantiation is about creating components via configurations. The actual creation work is done by the PRADO framework. For example, in an application configuration, 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 templates. 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 TButton component on the page,
+Static component instantiation is about creating components via configurations. The actual creation work is done by the PRADO framework. For example, in an application configuration, 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 templates. 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 TButton component on the page,
<com:TButton Text="Register" />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 @@
-A control is an instance of class TControl or its subclass. A control is a component defined in addition with user interface. The base class TControl defines the parent-child relationship among controls which reflects the containment relationship among user interface elements.
+A control is an instance of class TControl or its subclass. A control is a component defined in addition with user interface. The base class TControl defines the parent-child relationship among controls which reflects the containment relationship among user interface elements.
Controls refers to the child control collection of the parent.
+where the property Controls refers to the child control collection of the parent.
-Each control has an ID property that can be uniquely identify itself among its sibling controls. In addition, each control has a UniqueID and a ClientID which can be used to globally identify the control in the tree that the control resides in. UniqueID and ClientID 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 UniqueID or ClientID.
+Each control has an ID property that can be uniquely identify itself among its sibling controls. In addition, each control has a UniqueID and a ClientID which can be used to globally identify the control in the tree that the control resides in. UniqueID and ClientID 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 UniqueID or ClientID.
-Each control has a naming container which is a control creating a unique namespace for differentiating between controls with the same ID. For example, a TRepeater control creates multiple items each having child controls with the same IDs. 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 ID together with its own ID. As you may already have understood, UniqueID and ClientID 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 ID. For example, a TRepeater control creates multiple items each having child controls with the same IDs. 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 ID together with its own ID. As you may already have understood, UniqueID and ClientID rely on the naming containers.
-A control can serve as a naming container if it implements the INamingContainer interface.
+A control can serve as a naming container if it implements the INamingContainer interface.
-Viewstate and controlstate are implemented in TControl. 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 TControl. They are commonly used to define various properties of controls. To save and retrieve values from viewstate or controlstate, use following methods,
$this->getViewState('Name',$defaultValue);
$this->setViewState('Name',$value,$defaultValue);
$this->getControlState('Name',$defaultValue);
$this->setControlState('Name',$value,$defaultValue);
-where $this refers to the control instance, Name refers to a key identifying the persistent value, $defaultValue is optional. When retrieving values from viewstate or controlstate, if the corresponding key does not exist, the default value will be returned.
+where $this refers to the control instance, Name refers to a key identifying the persistent value, $defaultValue is optional. When retrieving values from viewstate or controlstate, if the corresponding key does not exist, the default value will be returned.
-A module is an instance of a class implementing the IModule 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 IModule 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.
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 configurations. @@ -14,34 +14,34 @@ There are three core modules that are loaded by default whenever an application
-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 THttpRequest as request module. The request module can be accessed via the Request 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 THttpRequest as request module. The request module can be accessed via the Request 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 THttpResponse as response module. The response module can be accessed via the Response 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 THttpResponse as response module. The response module can be accessed via the Response 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 THttpSession as session module, which is a simple wrapper of the session functions provided by PHP. The session module can be accessed via the Session 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 THttpSession as session module, which is a simple wrapper of the session functions provided by PHP. The session module can be accessed via the Session property of application and controls.
-Error handler module is used to capture and process all error conditions in an application. PRADO uses TErrorHandler 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 ErrorHandler property of the application instance.
+Error handler module is used to capture and process all error conditions in an application. PRADO uses TErrorHandler 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 ErrorHandler property of the application instance.
-PRADO is released with a few more modules besides the core ones. They include caching modules (TSqliteCache and TMemCache), user management module (TUserManager), authentication and authorization module (TAuthManager), etc.
+PRADO is released with a few more modules besides the core ones. They include caching modules (TSqliteCache and TMemCache), user management module (TUserManager), authentication and authorization module (TAuthManager), etc.
-When TPageService is requested, it also loads modules specific for page service, including asset manager (TAssetManager), template manager (TTemplateManager), theme/skin manager (TThemeManager), and page state persister (TPageStatePersister).
+When TPageService is requested, it also loads modules specific for page service, including asset manager (TAssetManager), template manager (TTemplateManager), theme/skin manager (TThemeManager), and page state persister (TPageStatePersister).
Custom modules and core modules are all configurable via configurations. 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.
-Each page must have a template file. The file name suffix must be .page. 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 .php) as the template file. If the class file is not found, the page will take class TPage.
+Each page must have a template file. The file name suffix must be .page. 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 .php) as the template file. If the class file is not found, the page will take class TPage.
-A form submission is called postback 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 TButton, we call it the postback event sender which will translate the postback event into some specific server-side event (e.g. Click and Command events for TButton).
+A form submission is called postback 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 TButton, we call it the postback event sender which will translate the postback event into some specific server-side event (e.g. Click and Command events for TButton).
-A service is an instance of a class implementing the IService 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 IService 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 uniquely identified by its ID property. By default when THttpRequest is used as the request module, GET variable names are used to identify which service a user is requesting. If a GET variable name is equal to some service ID, 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 page. For example, the following URL requests for the Fundamentals.Services page,
+A service is uniquely identified by its ID property. By default when THttpRequest is used as the request module, GET variable names are used to identify which service a user is requesting. If a GET variable name is equal to some service ID, 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 page. For example, the following URL requests for the Fundamentals.Services page,
http://hostname/index.php?page=Fundamentals.Services@@ -16,19 +16,19 @@ Developers may implement additional services for their applications. To make a s
-PRADO implements TPageService to process users' page requests. Pages are stored under a directory specified by the BasePath property of the page service. The property defaults to pages directory under the application base path. You may change this default by configuring the service in the application configuration.
+PRADO implements TPageService to process users' page requests. Pages are stored under a directory specified by the BasePath property of the page service. The property defaults to pages directory under the application base path. You may change this default by configuring the service in the application configuration.
-Pages may be organized into subdirectories under the BasePath. In each directory, there may be a page configuration file named config.xml, which contains configurations effective only when a page under that directory or a sub-directory is requested. For more details, see the page configuration section.
+Pages may be organized into subdirectories under the BasePath. In each directory, there may be a page configuration file named config.xml, which contains configurations effective only when a page under that directory or a sub-directory is requested. For more details, see the page configuration section.
-Service parameter for the page service refers to the page being requested. A parameter like Fundamentals.Services refers to the Services page under the <BasePath>/Fundamentals directory. If such a parameter is absent in a request, a default page named Home is assumed. Using THttpRequest as the request module (default), the following URLs will request for Home, About and Register pages, respectively,
+Service parameter for the page service refers to the page being requested. A parameter like Fundamentals.Services refers to the Services page under the <BasePath>/Fundamentals directory. If such a parameter is absent in a request, a default page named Home is assumed. Using THttpRequest as the request module (default), the following URLs will request for Home, About and Register pages, respectively,
http://hostname/index.php http://hostname/index.php?page=About http://hostname/index.php?page=Users.Register-where the first example takes advantage of the fact that the page service is the default service and
Home is the default page.
+where the first example takes advantage of the fact that the page service is the default service and Home is the default page.
\ No newline at end of file
--
cgit v1.2.3