Adding Reach Extensions to various pages in your intranet is a simple process because you have access to the source code for those pages. As a result you can embed the desired Reach Extension on every page and follow the Reach deployment best practices to improve efficiency. Achieving the same level of control in a third-party application is not always as straightforward.
Scenario: Suppose your host application is a bug tracking program and you want to embed a Reach Discussion on all “Issue” pages within the application. Let’s assume that every Issue page has an element with the ID issue_page and a container with the ID issue_discussion where you could append the Reach Extension.
Solution:Write a script that examines each page to see if it contains the element issue_page. If so, the script would designate the issue_discussion element as the container for the extension.
Scenario: Like Scenario 1, this scenario assumes that you want to embed a Reach Discussion on all “Issue” pages in your bug tracking application. This time, suppose that you need more control over where you place the extension on each page. We’ll assume that every Issue page has an issue_page element and a global footer with the ID global_footer.
Solution: Write a script that checks each application page to see if it contains the issue_page element. If so, the script would create a new element, append it to the global footer, and then specify the new element as the target Reach container.