The logic performed when a plug-in function is triggered from a checklist needs to come in a strictly tailored dress of standard definitions. Each script must carry definitions and
subroutines to establish a baseline of communication capabilities between the RayQC plug-in interface and the Checklist Viewer logic resolver.
The Plug-in Execution Procedure in a Nutshell
RayQC supports 2 kinds of plug-ins: Internal and External. The external plug-in type can be further divided into categories: local and global plug-ins. Although the scope of both local and external plug-ins is different,they do share the same plug-in execution logic. Each plug-in consists of a plug-in script and a manifest.xml file. The manifest file acts as an interface between the RayQC plug-in execution logic and the plug-in script. When a checklist containing the plug-in is loaded, the checklist is validated against the checklistschema.xsd file and the manifest file is validated against the manifestschema.xsd file. During execution, depending upon the plug-in logic, input parameters are passed to the plug-in script through the function which is defined in the manifest.xml file. If the function name and its arguments in the manifest file don’t match the ones in the script file, an error is thrown. After plug-in execution, the script returns the result value which in turn is mapped to the checklist element, called the plug-in, through the manifest file. For more information on the structure of checklists and its manifest files, refer to the Appendices chapter of this guide.
|
Note: The following section does not provide a full plug-in script sample, but describes the sections that need to be present. Please refer to the External plug-ins sample available from the application root directory (typically something like C:\Program Files (x86)\RayQC\Samples\), and the Appendix of this document for further code details. |
