MicroStrategy ONE

Style Catalog Configuration File

The Style Catalog Configuration file is an XML configuration file that contains the information and rules used to render data on a MicroStrategy Web page. This file, named styleCatalog.xml, defines all of the styles available to the application and all of the style-related information— including transform definitions, bean definitions, and the parsers and sources for layout definition files. Each individual style brings together the transform used by the style, any transform parameter values that should be used by that style in place of default values (including a CSS file to be used), and the layout definition that should be applied to the transform.

Web beans and web components access and contain data, but they do not contain any information on how the data should be displayed. The rules for converting the data contained in web beans are provided by the styles in the Style Catalog Configuration file.

The default name of the Style Catalog Configuration file is styleCatalog.xml, and the default location is under the WEB-INF/xml folder in the MicroStrategy installation directory. You can change the name or location for styleCatalog.xml, but, if you do so, you must  make the application aware of the new file name or location. To do this, you must modify the value of a parameter in web.xml, the MicroStrategy Web configuration file, which is located by default under the WEB-INF folder in the MicroStrategy installation directory. You set the value of the context parameter called styleCatalogFile file to the new location and name, as shown in the code sample below.

<context-param>

  <param-name>styleCatalogFile</param-name>

  <param-value>/_custom/WEB-INF/xml/styleCatalog.xml</param-value>

</context-param>

When you customize the Style Catalog Configuration file, the recommended practice is to make a copy of styleCatalog.xml, save it in your custom folder under _custom/WEB-INF/xml, and make your changes in the custom file. When you do this, you must make the change shown in the code sample above so that the application knows where to find the custom styleCatalog.xml file.

The path to a custom or relocated Style Catalog Configuration file (shown in bold in the code sample above) must be specified in one of two ways:

  • If the new location of the Style Catalog Configuration file remains inside the application context (that is, inside the MicroStrategy folder in a J2EE environment or the Web ASPx folder in a .NET environment), you can use a relative path, as in the following example.

    <param-value>/_custom/WEB-INF/xml/styleCatalog.xml</param-value>

  • If the new location of the Style Catalog Configuration file is located outside of the application context (that is, not inside the MicroStrategy folder in a J2EE environment or the Web ASPx folder in a .NET environment), you must specify an absolute file path. The parameter path value must be preceded by the key word ABSOLUTE: as in the following examples:

    <param-value>ABSOLUTE:/usr/web-mstr-cust/styleCatalog.xml</param-value>

    and

    <param-value>ABSOLUTE:/C:/web-mstr-cust/styleCatalog.xml</param-value>

Always use forward slashes (/) and never back slashes (\), whether working in a Windows or UNIX environment.

Refer to the Style Catalog Configuration File XML Structure topic for a detailed explanation of the XML elements and attributes in styleCatalog.xml. To see the visual representation of the most commonly used folder browsing styles, refer to the Styles Available for Folder Browsing Pages topic.

File read frequency

The Style Catalog Configuration file is read into memory by the servlet or corresponding ASP.NET file when the application is initialized. The default configuration is for the application to read this file only when the application is started, rather than to check for updates to the file with each successive request. Thus, by default, if the Style Catalog Configuration file is modified (as well as any other MicroStrategy Web XML configuration file), the application must be restarted to recognize these changes.

This is an effective strategy for a production environment. However, for development this may be inefficient. To change this behavior during development, see Applying customization changes.