Text file rules are one form of static content — rules that do not depend on clipboard values. When you save or check in a text form rule, any previous file on the Web server based on that name, directory, ruleset, and version is deleted. The directory path and file names are based on a hash code derived from ruleset version lists.
If you copy a Skin rule using the Save As toolbar operation, three text file rules (identified on the Styles tab for Desktop, Work and Report) are also copied.
When you circumstance a skin rule, the system copies the base rule's files and appends a datestamp and code string to each of the file names. For example, if you create a skin rule that uses a text file named reports_acmestandard and circumstance the skin, a text file named reports_acmestandard_20091102T201109_389 is created.
When you save a harnesses that references CSS rules (on the Scripts and Styles tab an optimized text file rule is automatically created with a name starting with pzHarness, saved in the same ruleset version as the harness.
If you save the harness again, a second optimized text file rule is created with a distinctive name, and the first is "orphaned". The Pega-RulesEngine agent deletes such orphaned rules.
When you use the Save As toolbar operation to copy a text file rule that contains CSS styles into a different ruleset, a warning appears if the CSS text references images (that is, binary file rules) that are not available to you. Note the names of these images and copy or create them into your application ruleset.
When a requestor first references a text file rule, the image file (or other binary file) is extracted as static content into an appropriate Web server directory on the server. It determines the destination directory from the rule key and a hash code derived from the requestor's ruleset list.
As a best practice, use the Skin rule to define the styles in your application. The Skin form maintains three CSS text files for your application, referenced in the skin rule.
However, if truly necessary, you can override these or other text file rules to change the appearance of your application user interface. Advanced CSS skills and techniques may be required. You can determine which text file rules you need to override by reviewing the output HTML of your application's harness forms.
Use the Rules Inspector tool to study the structure of harness forms, sections, and the HTML rules they reference.
Your browser has a workstation cache of recently received files. When testing updated or overridden text files for JavaScripts and CSS files, clear your browser cache to see the effect of some newly exported text files.
For Internet Explorer, select Tools > Internet Options > General > Temporary Internet Files > Delete Files. Select Delete all Offline Content to ensure that older versions of JavaScript files are also purged from the Internet Explorer cache. (Other browsers offer similar menu options to clear their caches.)
If the change is to affect many users, asking them to each clear their local cache may not be practical. By default, HTTP headers mark static elements to be cached for 24 hours, so users will receive the newer files a day later. If this is not satisfactory, you can set the defaultcachingtimeout element in the prconfig.xml file to a value lower than the default of 86,400 seconds (24 hours). For example:
<env name="http/defaultcachingtimeout" value="6000" />
A lower value causes more HTTP traffic and so can adversely affect response time.
As an alternative to updating the prconfig.xml file, you can use Dynamic System Settings to configure your application. See Dynamic System Settings data instances.
If authorized, you can use the System Management Application to delete all extracted static files from the HTTP server directory structure (on a specified node), forcing them to be extracted again on demand.
If your application rulesets contain text file rules with custom JavaScript, run the Rule Security Analyzer before locking a ruleset version, to look for possible security issues.