1. Initialization
When the controller passes control to the TagActionDispatcher, some initialization triggers to set ActionObjects and ViewResourcesConfig properties in order to use our template:
Regain the $form, $errors and $data objects from the request. If any of these objects have been created before (such as in the Action class), the object will now be invisible in the resource template, otherwise the object will be set to NULL.
Retrieve the reference of the ViewResourcesConfig object, which contains configuration parameters.
Set the path to the template source file and compiled template file in the ViewResourcesConfig parameter.
2. Set the tag page
The extension of the template source file (probably ".ssp") is used to compare it with the ViewResourcesConfig->tagFlagStr parameter to determine whether this page needs to be processed, otherwise the page will be processed as a standard (no tag) template file. We can configure the tag file extension in the view-resources element, just like this:
<view-resources
...
tagFlagStr = ".ssp"
tagFlagCnt = "-4"
...
</view-resources>
tagFlagStr indicates that the source file of the tag template can be preprocessed, such as:. This extension triggers the tag processing. The attribute tagFlagCnt defines the number of characters at the end of the file name, including "."(). According to an example, -4 represents the last 4 characters of the source file name. The default values are .ssp and -4, so if we use a template file name, we do not need to set these parameters.
3. Process the tag file
The template tag system decides whether to run the tag processor, and it must be based on the ViewResourcesConfig->processTags attribute. If this attribute is true, the template page (and the page it contains) will be processed by the tag processor class, otherwise the tag processor will not be called. The developer just needs to set it to true in development, and if false, it will not be processed. But it should be noted that when the processTags attribute is set to true, the modified tag page will be compiled (this depends on the compileAll attribute setting). We can define the processTags attribute in the view-resources element, just like this:
<view-resources
...
processTags = "True"
...
</view-resources>
Note that its default value is false.
4. Compile the template page.
If TagActionDispatcher decides that the template page will be processed, it will pass control to the template tag system. Now the template tag system will decide whether to compile only modified pages or compile all pages. This behavior is defined using the ViewResourcesConfig->compileAll property. We define the compileAll property like this:
<view-resources
...
compileAll = "True"
...
</view-resources>
This attribute defaults to false.
5. Only compile modified pages.
If the compileAll property is set to false (default), only modified pages will be compiled. According to an example, if the requested page has been modified since the last request, this page will be compiled.
6. Compile all pages.
If the compileAll property is set to true, the template tag system will always compile the page (including the included pages) regardless of whether the page has been modified since the last request. Developers use this option in development to ensure that all pages are processed.
7. Process VIEW resources.
After processing the template page, control returns to the TagActionDispatcher. The requested VIEW resource (template file) will be processed by any other positive-scale board file. The TagActionDispatcher regains the compiled page (including included pages) and outputs the page to the user's browser. If the template tag system is not called, the TagActionDispatcher processes the requested page as a regular VIEW resource. For example, the TagActionDispatcher can be used instead of the standard ActionDispatcher.
When the controller passes control to the TagActionDispatcher, some initialization triggers to set ActionObjects and ViewResourcesConfig properties in order to use our template:
Regain the $form, $errors and $data objects from the request. If any of these objects have been created before (such as in the Action class), the object will now be invisible in the resource template, otherwise the object will be set to NULL.
Retrieve the reference of the ViewResourcesConfig object, which contains configuration parameters.
Set the path to the template source file and compiled template file in the ViewResourcesConfig parameter.
2. Set the tag page
The extension of the template source file (probably ".ssp") is used to compare it with the ViewResourcesConfig->tagFlagStr parameter to determine whether this page needs to be processed, otherwise the page will be processed as a standard (no tag) template file. We can configure the tag file extension in the view-resources element, just like this:
<view-resources
...
tagFlagStr = ".ssp"
tagFlagCnt = "-4"
...
</view-resources>
tagFlagStr indicates that the source file of the tag template can be preprocessed, such as:. This extension triggers the tag processing. The attribute tagFlagCnt defines the number of characters at the end of the file name, including "."(). According to an example, -4 represents the last 4 characters of the source file name. The default values are .ssp and -4, so if we use a template file name, we do not need to set these parameters.
3. Process the tag file
The template tag system decides whether to run the tag processor, and it must be based on the ViewResourcesConfig->processTags attribute. If this attribute is true, the template page (and the page it contains) will be processed by the tag processor class, otherwise the tag processor will not be called. The developer just needs to set it to true in development, and if false, it will not be processed. But it should be noted that when the processTags attribute is set to true, the modified tag page will be compiled (this depends on the compileAll attribute setting). We can define the processTags attribute in the view-resources element, just like this:
<view-resources
...
processTags = "True"
...
</view-resources>
Note that its default value is false.
4. Compile the template page.
If TagActionDispatcher decides that the template page will be processed, it will pass control to the template tag system. Now the template tag system will decide whether to compile only modified pages or compile all pages. This behavior is defined using the ViewResourcesConfig->compileAll property. We define the compileAll property like this:
<view-resources
...
compileAll = "True"
...
</view-resources>
This attribute defaults to false.
5. Only compile modified pages.
If the compileAll property is set to false (default), only modified pages will be compiled. According to an example, if the requested page has been modified since the last request, this page will be compiled.
6. Compile all pages.
If the compileAll property is set to true, the template tag system will always compile the page (including the included pages) regardless of whether the page has been modified since the last request. Developers use this option in development to ensure that all pages are processed.
7. Process VIEW resources.
After processing the template page, control returns to the TagActionDispatcher. The requested VIEW resource (template file) will be processed by any other positive-scale board file. The TagActionDispatcher regains the compiled page (including included pages) and outputs the page to the user's browser. If the template tag system is not called, the TagActionDispatcher processes the requested page as a regular VIEW resource. For example, the TagActionDispatcher can be used instead of the standard ActionDispatcher.