Documentation Center

Best practices when creating custom publish compare plugins

Best practices when creating a new publish compare 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 for every content or metadata file that exist in the current or compare version folder.
  2. Implement Initialize. Here the plugin should read its parameters and parse their values. The initialize is only called once.
  3. Implement CompareXml and CompareMetadata. Note that a filepath parameter passed into the method can contain an empty string to indicate this file does not exist (in this version). Both methods should create a result file (on the file path provided in the resultFilePath parameter) and return the proper compare result. Through the plugin configuration you can get:
    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.
Multiple threads
The code surrounding the compare plugin runs multithreaded, so every custom compare plugin implementation needs to be thread safe.
Result file
The encoding in the XML result file should be correct, so if the file is saved with a byte order mark, use the correct corresponding value for the encoding attribute of the XML processing instruction.