- library/framework scripts, like jQuery
- component/plugin scripts that require a library, like jQuery UI, jQuery Colorbox
- common application-level scripts that are shared among multiple pages and might require the above
- We want to reduce duplicate functionality. As an example, there are dozens of lightbox-style scripts that do the same thing in a different way.
- We want to take advantage of caching—many JS files and libraries are large files, and if each of us link to and use the same files, we reduce our bandwidth and improve overall visitor experience.
The Review Process
Highly-regarded and well maintained third-party libraries may go through a shorter review process and be added to the Drupal WebCMS servers by OMS.
- Using Standard and Certified JS Files on Production Web Servers
Criteria for Approval
- OMS will approve the following:
- dynamic data presentation, such as from data files: CSV, JSON, XML;
- database calls to an EPA data source via AJAX/jquery;
- interactivity, including forms and form results.
- OMS will disapprove the following:
- Code that does not pass the JSHint (or JSLint) or EPA scanning processes;
- Code that is not properly licensed for use by EPA;
- Code that changes the EPA One Web look-and-feel (local styles are not allowed);
- Anything already part of the standard libraries or that can be achieved using JS files and libraries already approved;
Stage 1. Development
The Application owner begins development and testing of JS. The EPA specifically provides the Drupal WebCMS Sandbox server for this purpose. The sandbox server has the same code as the production environment, decreasing the testing and debugging time. There is no cost to step up a user account on the sandbox. If you have an account on the production server, you also have an account on the sandbox.
General Coding Rules
The long-term value of software is in direct proportion to the quality of the codebase. Over its lifetime, a program will be handled by many pairs of hands and eyes. If code is able to clearly communicate its structure and characteristics, it is less likely that it will break when modified in the never-too-distant future.
Stage 2. Security Checklist and Deployment
If the code passes review:
The JS files and libraries will be placed into the production repository (our revision control system). You will no longer have write access to the code. All changes to code will be recorded. Rollbacks to previous versions will be possible. You can request a rollback by emailing WebCMS Support (firstname.lastname@example.org).
If the code fails review:
As OMS will manage the revision control system, you will no longer have write access to your production JS file or library. You will modify your JS on the Sandbox server and, when testing is complete, make a JS Update Request by contacting us.
After the request has been received and confirmed with you, OMS will run a
If necessary, you can request that current code be rolled back to a previous version. To rollback, make a JS Update Request. One caveat: if the code is out of date, it will be subject to a new review before it is restored.
Stage 4. Retiring/Reactivating a JS File or Library
The script will be retired from active use, archived, and available for reactivation. To reactivate it, submit a JS Update Request. One caveat: if the code is out of date, it will be subject to a new review before it is restored.
Please note that OMS will review JS usage periodically. If the code has not been used or accessed in the last 60 days, you will be notified. You can then determine if the JS should remain operational or be retired.
One reason we're opening up JS for our content editors is captured in the image to the right, which shows an example of using JS to read and output data from an external data source (whether another EPA server or an uploaded data file).
DataTables or Highcharts, or other scripts, will help you display this external file-based data.