This is just a heads up to users that access my Pastie Database. I will be making substantial changes to the database over the next few months that I will announce here. The intent of these changes it...
With all major browser now supporting Service Workers I will be deploying a Service Worker to all of my QuickBase applications both public and private. This deployment will happen some time between now and the time of the Empower Conference. What follows is a description of the architecture I will be using.
I have a application entitled SW Master (with dbid=bnpp6kt9s) which currently has no tables but does have three code pages named as follows:
registration.html
swmaster.js
account.js
The registration.html page contains some simple code that will cause the code page swmaster.js to be registered as a Service Worker with a scope of my entire account. In practice I will embed the registration.html page in the dashboard of select applications as a web page widget. When a user visits this application the code in registration.html will cause the Service Worker in swmaster.js to become registered. At this point the user who triggered the registration will have every application in my account controlled by the Service Worker in the code file swmaster.js
Within swmaster.js there is code that will append three<script> tags to the bottom of every navigated page QuickBase serves. If the user is currently viewing page associated with the Pastie table (dbid=bgcwm2m4g), the appended code will look something like this:
The first script will point to a code page named table_<dbid>.js where <dbid> is the dbid of the current page's URL (the dbid bgcwm2m4g is for the Pastie Table). Code in table_<dbid>.js (eg table_bgcwm2m4g.js) will be responsible for customization or feature enhancements you want to add to a any page associated with a particular table. Unlike the IOL technique which are only operate against {new, view, edit, table report and gridedit} pages the injected script will apply to every page associated with the table including administrative and non-table reports.
The second script will point to a code page named application.js in the current application. Code in application.js will be responsible for application branding or application wide feature enhancements you want to add to every page in your application.
The third script will point to a code page in SW Master named account.js. Code in account.js will be responsible for account branding or account wide feature enhancements you want to add to every page in your account. Initially I will place code in account.js that will draw a red horizontal line across the top of the page to give visual feedback that Service Workers have been enabled.
The net effect of adding these three <script> tags is that you will get fine grain control of injecting script based on the (1) table, (2) application and (3) account (ie subdomain) that is currently being accessed.
We will be accomplishing all of these features enhancements with a singleService Worker because we will consistently be using the convention of naming the code pages table_<dbid>.js, application.js and account.js. If none of these code pages exist, the application will work as if the Service Worker was not doing anything.
It may sound complicated but this architecture has been carefully thought out over almost three years and it will blow your mind what you can do using Service Workers.