Service Worker Travel Log - Day 10
Day 10 - Show Me More!
Okay let's show some more uses of Service Workers with QuickBase. We have a cornucopia of use cases in our arsenal that will amaze and delight you all of which most QuickBase users would think are impossible. In fact, what you already know about Service Workers already empowers you to accomplish the impossible and we haven't even got to the good stuff yet. What will 20 more days of the Service Workers Travel Log yield?
Sometimes it is the littlest things that cause the most annoyance. For example when I create a new report I would prefer that the Report Builder preset some options by default such as selecting the Filter records option and selecting the <Some field> criteria as indicated here:
Instead QuickBase opens the Report Builder in the following state and I have to manually make the above changes:
So to fix this little annoyance let's use essentially the same Service Worker used on Day 7 to load a code page named bmt8x7tm6.js on every page within Table #7. We will further arrange for bmt8x7tm6.js to contain the following small piece of script that manipulates the form to our liking if we happen to be on the Report Builder page for Table #7:
We have again modified the Service Worker registration page (reg.html) to now register sw7.js with scope of bmtpmup9q (Table #7). Now just pass through the application dashboard to register our newest Service Worker sw7.js:
Service Worker Travel Log Dashboard
https://haversineconsulting.quickbase.com/db/bmtpmup9q
Next bring up the Report Builder for Table #7 and observe our desired changes have been applied automatically:
Modified Report Builder for Table #7
https://haversineconsulting.quickbase.com/db/bmt8x7tm6?a=ViewBuild
With a little imagination you can see that there are almost unlimited uses for this particular pattern.
Now you may be wondering why we didn't make our modifications to the Report Builder page in the Service Worker itself. Well one reason is that the Service Worker does not have access to the DOM (Document Object Model) so we could not use the two concise jQuery statements in the code page bmt8x7tm6.js to accomplish this goal. But a second reason is more important.
What if we just used a single generic Service Worker to inject a <script> tag on every page in the application referencing a code page named after the dbid with the extension ".js" through the src attribute? Well it turns out that this and similar conventions of using Service Workers with QuickBase work out extremely well.
Next Up: Day 11 - Will it Blend?
Okay let's show some more uses of Service Workers with QuickBase. We have a cornucopia of use cases in our arsenal that will amaze and delight you all of which most QuickBase users would think are impossible. In fact, what you already know about Service Workers already empowers you to accomplish the impossible and we haven't even got to the good stuff yet. What will 20 more days of the Service Workers Travel Log yield?
Sometimes it is the littlest things that cause the most annoyance. For example when I create a new report I would prefer that the Report Builder preset some options by default such as selecting the Filter records option and selecting the <Some field> criteria as indicated here:
Instead QuickBase opens the Report Builder in the following state and I have to manually make the above changes:
So to fix this little annoyance let's use essentially the same Service Worker used on Day 7 to load a code page named bmt8x7tm6.js on every page within Table #7. We will further arrange for bmt8x7tm6.js to contain the following small piece of script that manipulates the form to our liking if we happen to be on the Report Builder page for Table #7:
(function(){
var querystring=document.location.search;
if (/a=ViewBuild/i.test(querystring)) {
$("#Radio2")[0].click();
$("#critFID_0").val("0").trigger("change");
}
})();I will note in passing that these particular statements emulate user input and emulating user input is generally the safest way to customize a QuickBase page with script.We have again modified the Service Worker registration page (reg.html) to now register sw7.js with scope of bmtpmup9q (Table #7). Now just pass through the application dashboard to register our newest Service Worker sw7.js:
Service Worker Travel Log Dashboard
https://haversineconsulting.quickbase.com/db/bmtpmup9q
Next bring up the Report Builder for Table #7 and observe our desired changes have been applied automatically:
Modified Report Builder for Table #7
https://haversineconsulting.quickbase.com/db/bmt8x7tm6?a=ViewBuild
With a little imagination you can see that there are almost unlimited uses for this particular pattern.
Now you may be wondering why we didn't make our modifications to the Report Builder page in the Service Worker itself. Well one reason is that the Service Worker does not have access to the DOM (Document Object Model) so we could not use the two concise jQuery statements in the code page bmt8x7tm6.js to accomplish this goal. But a second reason is more important.
What if we just used a single generic Service Worker to inject a <script> tag on every page in the application referencing a code page named after the dbid with the extension ".js" through the src attribute? Well it turns out that this and similar conventions of using Service Workers with QuickBase work out extremely well.
Next Up: Day 11 - Will it Blend?