Use the configuration properties to configure theme and modules

Create a JavaScript object for the theme on the client side. Theme metadata.properties must be loaded dynamically. To load a property statically, use a resource environment provider custom property.

Configuration properties can be loaded either statically, type="config_static", or dynamically, type="config_dynamic". Use one or the other or both depending on the needs. Static is intended for property values that do not commonly change after they are loaded initially, and is better for performance because the values are cached. Dynamic is intended for property values that change more frequently.

All configuration properties the module must reference on the client side are merged together into a single convenient global config object. They are merged whether they are theme metadata properties or resource environment provider custom properties. We can then reference any property within the object...

myCoCfg.themesConfig

...such as...

myCoCfg.themesConfig.myTheme_myRepProperty

The theme and the modules provided with HCL WebSphere Portal merge their configuration properties into the ibmCfg global variable. We can run this variable in a browser console and inspect what the property names and values are. Changes to values in the WP GlobalThemeConfig REP are global to all themes. We can override certain values on the client side if we need the values to be different in only the themes that include the module. We can do so with syntax similar to the following example in one of the config*.jsp files for my module:

i$.merge({
<%-- --%>
ibmCfg: {
    <%-- --%>
    themeConfig: {
    <%-- --%>
    loadingImage: "css/images/myloading.gif"
    <%-- --%>
}}});

If the module requires the module,wp_portal then the portal configuration loads before the configuration for the module, ensuring the override is merged in last.

1. Create an extension point (module definition) in the plugin.xml file for the theme with subcontributions for the configuration of the module.

   <extension point="com.ibm.portal.resourceaggregator.module" >
     <module >
          <prereq />
          <contribution type="config">
   
          <sub-contribution type="config_static">
             <uri value="res:{war:context-root}/mymodule/markup/config_global.jsp" />        
          </sub-contribution>
   
          <sub-contribution type="config_dynamic">
             <uri value="res:{war:context-root}/mymodule/markup/config.jsp" />           
          </sub-contribution>
         </contribution>
        </module>   </extension>

2. Add the moduleID to the profile file for the theme so the module loads.

   1. Connect the WebDAV client to http://localhost:port/wps/mycontenthandler/dav/fs-type1/.

   2. From the profiles folder within the folder for my theme, copy the profile_deferred.json file to a local drive.

   3. Rename the profile_deferred.json file to create a custom profile.

   4. Modify the local copy of the file and add the moduleID at the end of the list:
      , "myprefix_mymodule"

   5. Copy the custom profile JSON file into the profiles folder in the folder for the theme in fs-type1 on the portal server.

3. Create the config_global.jsp file, config.jsp file, or both in the modules web application in the \mymodule\markup folder.

   The following example of config.jsp file loads dynamically. A config_global.jsp file (static) would look similar, only without any theme metadata properties in it.

   <%@ page session="false" contentType="text/javascript;charset=ISO-8859-1" buffer="none" %>
    <%@ page trimDirectiveWhitespaces="true" %>
    <%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v8.5/portal-fmt" prefix="portal-fmt" %>
    i$.merge({<%--
       --%>myCoCfg: {<%--
        --%>themesConfig: {<%--
         --%>modules_contextRoot: "<portal-fmt:out escape="json">${wp.rep["REP.YourPrefix ThemesConfig"]["modules.contextRoot"]}</portal-fmt:out>",<%--
         --%>myTheme_contextRoot: "<portal-fmt:out escape="json">${wp.rep["REP.YourPrefix ThemesConfig"]["myTheme.contextRoot"]}</portal-fmt:out>",<%--
         --%>myTheme_myRepProperty: "<portal-fmt:out escape="json">${wp.rep["REP.YourPrefix ThemesConfig"]["myTheme.myRepProperty"]}</portal-fmt:out>",<%--
         --%>myTheme_myMetadataProperty: "<portal-fmt:out escape="json">${wp.themeConfig["myTheme.myMetadataProperty"]}</portal-fmt:out>"<%--
         --%>myModule_myRepProperty: "<portal-fmt:out escape="json">${wp.rep["REP.YourPrefix ThemesConfig"]["myModule.myRepProperty"]}</portal-fmt:out>",<%--
   --%>}}});

   If the myCoCfg global variable and themesConfig child property do not exist, the merge automatically creates them. We can also mix in my properties with any other properties that might already be present if the myCoCfg object exists.

4. If we have JSP reloading turned on in the web applications, then restart the web application for the modules and the web application for the theme. Otherwise, restart the portal server.

5. Restart the portal server.

Parent Configure the portal theme and modules