The Platform Theme System manages all files needed to skin our server-based thin-client offerings (BA Server and plugins). It was designed to satisfy the following goals:
- Eliminate the need for web and plugin developers to manually manage CSS
- All theme assets need to be automatically injected into every page displayed by our server
- Allow Customers/OEMs/etc to contribute new themes via plugins
- Separate "core" theme files from plugin-specific ones
- Provide extensible architecture for providing plugins via unanticipated methods
The Theme System API has two main interfaces: IThemeManager and IThemeResolver.
The name "manager" is a bit of a misnomer. It simply serves to provide all known themes in the system. The IThemeManager api is designed to have a list if IThemeResolvers injected into it, which is consults to find all available themes in the system.
getSystemThemeIds() is called when a list of available themes (onyx, crystal, etc.). Later calls to getSystemTheme() and getModuleTheme() return the respective definitions for the System or "global" Theme and the Module or "local" Theme.
Theme Resolvers are called upon to find themes in the system.
The default implementation of the IThemeManager caches results from the resolvers in the Platform CacheManager to reduce memory overhead.
This resolver finds theme definitions within Platform Plugins.
ServletContext resolver finds themes from top-level folders in the Pentaho WAR.
Note: Both of these stock resolvers use the same theme.xml file format to describe theme assets
Known limitations / Weaknesses
- Concept of "local" theme breaks down with common extension points like Visualizations, which while not part of the core are also not plugin specific
- Impossible to contribute to existing Global or Local themes. This forces customers to modify the theme.xml files from our plugins
- Enable usage outside of the server environment, such as PDI client and PRD
- Support supplying theme definitions from OSGI bundles