Put the shared functions in a managed web asset (a .js file in the toolkit) and include it in one small coach view that every human service drops on its coach - the functions become globals of the coach page, the client-side scripts of the CSHS can call them.
- Toolkit > Web files > upload common.js:
// common.js (managed web asset) - one namespace, no globals leaking
window.myco = window.myco || {};
myco.isEmail = function (s) { return /^[^@\s]+@[^@\s]+\.[^@\s]+$/.test(s || ""); };
myco.addDays = function (d, n) { var r = new Date(d); r.setDate(r.getDate() + n); return r; };
myco.deepGet = function (o, path) { return path.split(".").reduce(function (x, k) { return x == null ? x : x[k]; }, o); };- Coach view Common Library (no binding, no HTML): Behavior > Included Scripts: add common.js. Put this view once on every coach (or into a header coach view you already use).
- Any client-side script or control event of the CSHS can now use myco.isEmail(${Email}.getData()). Coach views load their included scripts once per page, so the functions are available from the coach's load event onwards.
Server-side scripts (service flows) cannot include a JS file; there the pattern is a toolkit service per function, or - the pragmatic one - a script that defines the functions stored in an environment variable / EPV and evaluated with eval(tw.env.commonJs) (works, keep it small), or a Java integration with the logic in Java.
Keep the library in a toolkit so that every process app gets the same version, and version the file name (common-1.2.js) when you change signatures.
References