Pastie Database Changes

When I have a free moment I am making changes to this application and I am currently working on entering the [Cateogry Type] for all 500+ records. I have noticed in a lot of case I have provided script intended to be used with the IOL technique but without the outer closure

(function() {

  //script goes here

})();

I have classified these pasties as Script rather than IOL Module for the time being but in all cases the script should be wrapped in a closure so that local variables in the script do not conflict with QuickBase's global variables. Eventually this will all get cleaned up but it is a background task.

Through a combination of script and manual processing of outliers, I have added a [Content Type] to all the records in the Pastie Database as well as added a query for all records in each [Content Type]. There are certainly misclassified records and there is a lot more cleanup, normalization and expansion work I plan to do but this is an iterative process much like forming a vase on a potter's spinning wheel. Some queries return no records because the content was posted directly in the forum and not entered into the database. One content type is worth mentioning as an example of this: Chrome Dev Snippet. Chrome Dev Snippets were introduced in this forum post and I have now added the script to the Pastie Database:

What are QuickBase Snippets?
https://quickbase-community.intuit.com/questions/1188325-what-are-quickbase-snippets

I have hundreds if not thousands of unique content pieces that will eventually get pulled from the forum post or elsewhere, entered and classified so it will be that much easier to locate and use the content.

Here is a list of Content Type reports:

[Content Type] = Formula
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=64

[Content Type] = IOL Module
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=65

[Content Type] = Service Worker
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=66

[Content Type] = UserScript
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=67

[Content Type] = Console Script
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=68

[Content Type] = Technique
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=69

[Content Type] = Bookmarklet
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=70

[Content Type] = Code
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=71

[Content Type] = HTML
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=72

[Content Type] = CSS
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=73

[Content Type] = Template
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=74

[Content Type] = Chrome Dev Snippet
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=75

[Content Type] = Script
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=76

[Content Type] = URL
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=77

[Content Type] = EMPTY
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=78

[Content Type] = SQL
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=q&qid=79

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:

<script src='bgcwm2m4g?act=dbpage&pagename=table_bgcwm2m4g.js'></script>
<script src='bgcwm2m4g?act=dbpage&pagename=application.js'></script>
<script src='bnpp6kt9s?act=dbpage&pagename=account.js'></script>

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 single Service 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.

From time to time during the days before Empower I will be making substantial changes to all of my public applications and the Pastie Database in particular. During this time the appearance, behavior and availability of some of the applications may be effected. One change you will see if you visit the Pastie Database is that a Service Workers which I call "Scheme 0" is registered.

Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m3z

After visiting this page you will see the following markup at the bottom of the page's source:

</body>
</html>
<script src=bgcwm2m3z?act=dbpage&pagename=table_bgcwm2m3z.js></script>
<script src=bgcwm2m3z?act=dbpage&pagename=application.js></script>
<script src=bnpp6kt9s?act=dbpage&pagename=account.js></script>

What has happened is that a Service Worker is registered which injects three script into every page in my account.

The first script injected (table_bgcwm2m3z.js) is named after the table dbid in the URL.

The second script (application.js) is injected into every page in the application.

The third script (account.js) injected into every page in my entire account.

For the most part you will see no fundamental different in behavior of the demos as most of my applications do not have an applications.js or table_<dbid>.js files define (yet!). In this case the browser essentially ignores the injected <script> tags because it can't find the source file. Demos that explicitly used a Service Worker may no longer work on a case by case basis as browsers can only have one Service Worker registered at a time for a given scope. These effected demos will get converted or restored to working order over time.

There are a lot of additional changes and features I will be enabling so stay tuned as your QuickBase experience is about to explode.

If you have any questions feel free to ask me here or off-world using the information in my profile:

https://getsatisfaction.com/people/dandiebolt/

BTW, you may be surprised to see the <script> tags inserted after the closing <html> tag. This is of no consequence as the browsers will not be confused. This was done intentionally to make the Service Worker logic dead simple (ie add three <script> tags to the end of the page's existing source).