The modularization framework decouples feature enablement from the theme code itself. Themes can be developed more easily with little knowledge about the details of how underlying code for a feature works. Logical points are provided where modules can contribute data into a theme at run time and then optimize those contributions by combining them where possible. Multiple disparate remote sources can be combined into one request for greater performance.
The features of a theme can be enabled and disabled by using a profile to configure them. You can then focus your time on the interface design of the theme without being concerned about the details of getting the features to work correctly within their theme. It is easy to turn off features that are not needed in one environment that might be used in another environment. For example, you can disable editing capabilities in a production portal environment, while they are enabled in a development environment. The same theme code can be used across such environments where the only variable is the module inclusion profile.
Modules are registered extensions that are then used by a module profile. Each module is enumerated by the modules unique identifiers. A module might require other modules to allow the automatic inclusion of necessary code that is required to make a particular feature work. For example, you can use of the Dojo Toolkit within a module. A module can use the Dojo Toolkit to build custom widgets. To separate the code for the module from the Dojo code, the module requires certain Dojo modules to ensure that the code is loaded in the correct sequence. This separation allows greater serviceability by decoupling the packaging of the code for each module.
Basic artifacts and their relationParent topic: Developing themes and skins
The theme modularization framework foresees the following major artifacts and relations to one another.
Modules can contribute different types of data to the extension points within the page.
Deferred and nondeferred modules
The module framework allows a profile to specify whether to defer a particular module. By default, a module is loaded when the initial page loads, but modules that are specified as deferred modules are loaded after the page loads.
Response rendering for themes
To increase the response time of your portal, a template parser resolves which modules are needed and collects all of the modules that are enabled by the current profile. Parts of the content are parsed and displayed as soon as possible.
Registering theme modules
You can register theme modules and create and use profiles for a particular theme.
Specifying profile files
You must define which modules are used to render a page. Profiles specify which modules are loaded on a page or whether they are deferred to after a page loads.
Modules that are provided with the modularized theme
® Portal provides a set of ready-to-use modules.
Adding or removing a ready-to-use module to a theme
To add or remove a theme, update the profile that defines the modules that we use to render a page for the theme.
Portal offers a filtering feature for portlet capabilities based on the existing client side capabilities.