Deployed 673c68c with MkDocs version: 1.4.2

development_guide/index.html

@@ -1274,8 +1274,8 @@ <h3 id="running-your-tests">Running your tests</h3>
 <p><code>python tests/islandora_tests.py TestMyNewTest TestMyOtherNewTest</code></p>
 <h2 id="islandora-workbench-integration-drupal-module">Islandora Workbench Integration Drupal module</h2>
 <p><a href="https://github.com/mjordan/islandora_workbench_integration">Islandora Workbench Integration</a> is a Drupal module that allows Islandora Workbench to communicate with Drupal efficiently and reliably. It enables some Views and REST endpoints that Workbench expects, and also provides a few custom REST endpoints (see the module's README for details).</p>
-<p>Generally speaking, the only situtation where the Integration module will need to be updated is if we add a new feature to Workbench that requires a specific View or a specific REST endpoint to be enabled and configured in the target Drupal. If a change is required in the Integration module, it is very important to communicate this to Workbench users, since if the Integration module is not updated to align with the change in Workbench, the new feature won't work.</p>
-<p>As a developer, one way of ensuring that changes in the client-side Workbench code that depend on changes in the server-side Integration module will work is, within the Workbench code, invoke the <code>check_integration_module_version()</code> function to check the Integration module's version number and use conditional logic to execute the new code only if the Integration module's version number meets the requirements. Under the hood, this function queries <code>/islandora_workbench_integration/version</code> on the target Drupal to get the Integration module's version number, although as a developer all you need to do is invoke the function and inspect its return value.</p>
+<p>Generally speaking, the only situtation where the Integration module will need to be updated (apart from requirements imposed by new versions of Drupal) is if we add a new feature to Workbench that requires a specific View or a specific REST endpoint to be enabled and configured in the target Drupal. If a change is required in the Integration module, it is very important to communicate this to Workbench users, since if the Integration module is not updated to align with the change in Workbench, the new feature won't work.</p>
+<p>A defensive coding strategy to ensure that changes in the client-side Workbench code that depend on changes in the server-side Integration module will work is, within the Workbench code, invoke the <code>check_integration_module_version()</code> function to check the Integration module's version number and use conditional logic to execute the new Workbench code only if the Integration module's version number meets the requirements you define in your code (e.g., the new Workbench feature requires version 1.1.3 of the Integration module). Under the hood, this function queries <code>/islandora_workbench_integration/version</code> on the target Drupal to get the Integration module's version number, although as a developer all you need to do is invoke the function and inspect its return value.</p>
 <p>Note that some Views required by Islandora Workbench are defined by users and not by the Islandora Workbench Integration module. Specifically, Views described in the "<a href="https://mjordan.github.io/islandora_workbench_docs/generating_csv_files/">Generating CSV files</a>" documentation are created by users.</p>