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
- 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.
- Implement
Initialize. Here the plugin should read its parameters and parse their values. - 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:- Common parameters for the complete publish operation
- Plugin specific parameters
XmlResolverto resolve DTDsLogServiceandEventMonitorinterfaces, which can be used for logging
- Expose the plugin using the Export attribute to make sure that the plugin engine can discover the plugin.
General best practices
-
Pass
falseto 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 tofalse, you get a security error. This parameter,initializeCallContext, when set tofalse, 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
ReportItemsare structured by language, the root map cannot be added to theReportItems. 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
ReportItemsare provided as in-memory objects to allow fast access to specific objects/files...so use them as much as possible.