There are two main types of script policies: aggregating and non-aggregating. Non-aggregating script policies can contain a number of variants. The script content can either be embedded in the variant, or in an external resource referenced from the variant. At run time, MCS selects and uses the most appropriate version of the script for the device accessing the page. Typically, the embedded content is inserted into the page, while the external resource is referenced from the page. However, this behavior may depend on device capabilities.
There are two main types of script policies: aggregating and non-aggregating. Non-aggregating script policies can contain a number of variants. The script content can either be embedded in the variant, or in an external resource referenced from the variant. At run time, MCS selects and uses the most appropriate version of the script for the device accessing the page. Typically, the embedded content is inserted into the page, while the external resource is referenced from the page. However, this behavior may depend on device capabilities.
It is a good practice to create scripts as small modules that can then be easily reused. However, over time that approach will lead to a large number of script modules, and many of these modules will depend on functionality provided by other modules. Attempting to keep track of those dependencies manually can be a very difficult task. Allowing each script to declare its dependencies enables automatic resolution and ordering of those dependencies on the client. Page authors may also want to create custom groups of policies that balance application specific needs relating to three often competing aspects of reusability, performance and payload, against performance. Aggregating policies address these issues.
Aggregating policies do not have script content of their own, instead they are constructed from the script content of imported policies. The policies are imported either explicitly by reference or indirectly by importing features that are exported by policies built into MCS. Please note that it is not possible for an aggregating policy to import a feature that is not built into MCS, however it can reference policies that it requires to be included in the page before itself.
At present remote projects do not support aggregating script policies.
The content of an aggregated script is constructed from the content of all the policies that are imported by the aggregating script, i.e. the imported scripts, whether by importing features or policies, are considered to be a part of the aggregating policy, but the required scripts are not. The purpose of required scripts is to allow an aggregating script to reuse another aggregating script or policy without including it. For example, the following graph shows all the policies imported by the aggregating policy A1. In that case the page will contain only one link to the policy.
A1
/ \
P1 P2
/ \ / \
P3 P4 P5
/ \
P6 P7The aggregating policy shown in the following graph would cause exactly the same content to be sent to the device as the previous, however, its structure is different. The A2 aggregating policy has declared P5 to be a required script; A2 > P5 means "A2 requires P5". In that case the page will contain two links, the first to the aggregating policy P5, the second to the aggregating policy A2.
A2 > P5 P5
/ \ / \
P1 P2 P6 P7
/ \ /
P3 P4There are two types of conflicts that can arise during the processing of aggregating scripts: overlaps and enhancement conflicts.
If a page includes two or more aggregating scripts that overlap, i.e. use the same set of policies, then it will cause the scripts that provide those overlapping features to be included in the page twice, and this may lead to some client-side problems. The way to resolve an overlap between two aggregating script policies is to add to both a required script that imports all the overlapping policies. Unfortunately, it is not possible to automatically resolve overlaps because the overlap will be specific to the set of policies used in a page, and those policies could be used in different combinations on other pages. Also, if the aggregated scripts are generated by a servlet, then the information about the required scripts would have to be added to the URL to the servlet, and that could possibly lead to issues on devices that have limits on the size of URLs.
The way to resolve an overlap between two aggregating script policies is to add to both a required script that imports all the overlapping policies. For example, let's consider the following structure.
A1 A2
/ \ / \
P1 P2 P3 P4
\ /
P5
/ \
P6 P7This conflict can be resolved by creating a new aggregating script R3 that imports P5, and by modifying A1 and A2 so that the both policies require R3. The corrected structure will look like the following example. A1 > R3 indicates that A1 requires R3.
A1 > R3 A2 > R3 R3
/ \ / \ |
P1 P2 P3 P4 P5
/ \
P6 P7An enhancement conflict exists if for any policy P the following are true:
policy E enhances policy P,
policy U uses policy P, and
policies P and U are owned by a single aggregating policy that is different to the owner of the policy E.
The reason this is a problem is that the scripts are expected to be executed in the following order: P → E → U, so that the enhancements that E makes to P are available when U is executed. Unfortunately, if P and U are in the same aggregating policy but without E, then the only possible orders of execution are either (P, U) → E or E → (P, U). The conflict can be resolved be moving all three policies to the same aggregating policy, by moving U to the policy that contains E, or by moving U to a separate policy.
The order in which the content of script policies are executed on the client is determined by the order they appear in the output document which, in turn, is primarily determined by the dependencies between those scripts, but will also, where possible, preserve the order they were used within the document. However, please note that an imported or required policy will be executed before any importing or requiring policies, and a policy that enhances some other policy will be executed before the policy which uses it.