Documentation Center

Best practices for creating custom combine languages plguins

Best practices when creating a new combine languages plugin lets you get the best out of your customization.

Implementation plan

  1. Choose the category of the plugin. This plugin is called at a specific moment in time. Any custom plugin should minimally combine the maps of the different languages into one root map and return the file path to this root map. Of course, this plugin can also be used to do other custom processing that is related to multiple languages in one publication.
  2. Implement Initialize. Here the plugin should read its parameters and parse their values.
  3. Implement Run. Here you put the main logic of the plugin. Anything that plugin can do is available to it through the configuration, which includes:
    1. Common parameters for the complete publish operation
    2. Plugin specific parameters
    3. XmlResolver to resolve DTDs
    4. LogService and EventMonitor interfaces, which can be used for logging
  4. Expose the plugin using the Export attribute to make sure that the plugin engine can discover the plugin.

General best practices

Pass false to any API 2.5 constructor
Make sure to pass one parameter, set to false, to any API 2.5 constructors you use in your plugin. Without this parameter included and set to false, you get a security error. This parameter, initializeCallContext, when set to false, causes the call context to be reused, effectively keeping your code within the same process.
Make your root map in the final format
Since the ReportItems are structured by language, the root map cannot be added to the ReportItems. So, the generated root map should be saved in the "final" format with resolved DTD, because out-of-the-box post process plugins will NOT process this file.
Use the ReportItems
The ReportItems are provided as in-memory objects to allow fast access to specific objects/files...so use them as much as possible.