Make locations of webform link and inline ajax webform alterable #37

[patdunlavey]

Ticket: https://github.com/commonmedia/islandora_webform/issues/37

What does this Pull Request do?

Enables more flexibility in location and behavior of webform links on the object page.

What's new?

• Adds a checkbox to the module configuration page (/admin/islandora/configure/iw): "Append webform links to bottom of object view?" Default is yes, and causes the webform links to be displayed below the object, as before. When unchecked, they will not be displayed, and it is up to the site themer to place them on the page.
  • Adds a hook to alter the ajax commands that are run when the inline webform loads. This can make the webform load into a div elsewhere on the page.
  • Adds a hook to alter the markup for each webform link.
  • Adds a bit of configuration instructions to README.md

How should this be tested?

• Install islandora_webform, webform and webform_ajax; create a webform configured to display a link to an inline webform for an islandora object. Does the link appear and load the webform as before?
• Go to /admin/islandora/configure/iw and uncheck the checkbox "Append webform links to bottom of object view?". Do webform links no longer appear?
• Modify any template involved in displaying the object page to add an empty target div for the webform that can be uniquely identified by id or class; Implement hook_iw_inline_webform_ajax_commands_alter along the lines of the example provided in islandora_webform.api.php to change the jquery-selector target this div. Re-enable "Append webform links to bottom of object view?" on the islandora webform configuration page. Does clicking on the webform link cause the webform to be loaded into this alternate location on the page?
• Implement e.g. a preprocess function to load the themed weblinks into $variables; then modify the corresponding template file to display them; Disable "Append webform links to bottom of object view?" so that the webform links do not appear in the default location below the object. Do the webform links appear in the new location and behave as expected?

Additional Notes:

• Does this change require documentation to be updated? Yes, and is included in the PR
• Does this change add any new dependencies? No
• Does this change require any other modifications to be made to the repository (ie. Regeneration activity, etc.)? No
• Could this change impact execution of existing code? No

Interested parties

@petermacdonald @McFateM

[DiegoPino]

@patdunlavey looks good (got the notification and felt the need to say something)! Wondering if at some point in time you would like to run some automated Travis-CI and some integration tests(just maybe) for the XML form dependency part. Good work!

[petermacdonald]

Pat:

I wrote a long reply here yesterday, but I failed to actually Submit it when I got distracted by the weather. Anyway, the gist of the comment was that I installed the Islandora 7x.1-9 Vagrant image and followed your instructions as far as I could:

"Install islandora_webform, webform and webform_ajax; create a webform configured to display a link to an inline webform for an islandora object. Does the link appear and load the webform as before?"

MY RESPONSE: Yes, it does, but the IW gave me an error message while configuring Islandora Ingest for my webform, but that message went away after I installed the "Islandora Example Simple Text" module.

"Go to /admin/islandora/configure/iw and uncheck the checkbox "Append webform links to bottom of object view?". Do webform links no longer appear?"

MY RESPONSE: When I go to "/admin/islandora/configure/iw" I don't see "Append webform links to bottom of object view?" Do I need to apply a patch or Pull request? If so, please walk me through the steps.

Peter

[noahwsmith]

@patdunlavey should this be discarded, or rebased on top of the latest code?

[patdunlavey]

The should NOT be discarded. We rely on this in our own work for every implementation of islandora webform. Any rebase will require reconciling merge conflicts. Next steps would be to reconcile the merge conflicts on the source branch and re-test functionality, before re-requesting a review of this pull request.

[patdunlavey]

I inspected the code changes in this old pull request, and find that all the changes in this PR were in fact already been incorporated into the ICG 7.x branch. This happened over the course of several commits made by me in April 2017.

No further action is required. Closing.