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
- 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.
- Implement
Initialize. Here the plugin should read its parameters and parse their values. The initialize is only called once. - Implement
CompareXmlandCompareMetadata. Note that afilepathparameter 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 theresultFilePathparameter) and return the proper compare result. Through the plugin configuration you can get:- 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. - 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.