Forum Discussion

_anomDiebolt_'s avatar
Qrew Elite
8 years ago

Pastie Database Changes

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 to minimize the number of explanations I have to make to routine usage questions and to prepare for an onslaught of new content. One change I am making now is to specify a [Content Type] field which will categorize the code in the [Content] field. Here are the Content Type's I am initially using:

Unsorted - old entries that have not been re-categorized yet
Formula - [Content] is a standard QuickBase formula
IOL Module - [Content] is an Image Onload module.js file
Service Worker - [Content] is a Service Worker script
UserScript - [Content] is a User Script (Greasemonkey, Tampermonkey etc)
Console Script - [Content] is a script intended to be entered through the Developer Tools Console tab
Technique - [Content] is a narrative description of a technique
Bookmarklet - [Content] is a bookmarklet
Code - [Content] is a fragment of code which Transpiles to JavaScript (CoffeeScript, TypeScript etc)
HTML - [Contnet] is a fragment of HTML code
CSS - [Content] is a fragment of CSS code
Template - [Content] is a template (Underscore Template, Mustache Template etc)
Chrome Dev Snippet - [Content] is a Chrome Developer Tool Snippet
Script - [Content] is a script (might be the body of a closure for IOL)
URL - [Content] is a URL
SQL - [Content] is a SQL query

Hopefully this change will allow users to more quickly understand how the code in the [Content] is used without an individual explanation.

Pastie Database

4 Replies

  • 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?

    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

    [Content Type] = IOL Module

    [Content Type] = Service Worker

    [Content Type] = UserScript

    [Content Type] = Console Script

    [Content Type] = Technique

    [Content Type] = Bookmarklet

    [Content Type] = Code

    [Content Type] = HTML

    [Content Type] = CSS

    [Content Type] = Template

    [Content Type] = Chrome Dev Snippet

    [Content Type] = Script

    [Content Type] = URL

    [Content Type] = EMPTY

    [Content Type] = SQL

  • 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

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

    <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:

    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).