What is the [script] technique?

  • 2
  • 2
  • Question
  • Updated 2 years ago
  • Answered

What is the [script] technique?

Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 30,044 Points 20k badge 2x thumb

Posted 3 years ago

  • 2
  • 2
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 30,044 Points 20k badge 2x thumb
The [script] technique is a simple variation on the IOL technique that makes using the IOL technique dead simple because there is nothing to specify in the formula. All you have to do is drop the image on load variable (typically named [-]) on your form and you will immediately be setup to use the IOL technique on all the tables in your application. Here is the definition of the [-] text formula field with some HTML allowed:

[script]

Here is the definition of the user defined variable [script]:

<img qbu='module' src='/i/clear2x2.gif' onload="if(typeof QBU=='undefined'){QBU={};$.getScript(gReqAppDBID+'?a=dbpage&pagename='+gReqDBID+'_'+gDFID+'.js&rand='+new Date().getTime())};">


The [script] formula accessed three QuickBase global variables:

  1. gReqAppDBID - The application dbid
  2. gReqDBID - the table dbid
  3. gDFID - the form dbid (defaults to 2)
Placing [script] on your form will automatically load a user defined page from you application named:

<gReqDBID>_<gDFID>.js

If this file does not exist nothing special will happen nor will any error be generated. So if you get in the habit of defining a user defined variable named [script] in your application all you have to do to use the IOL technique is to create the user defined page named "<gReqDBID>_<gDFID>.js".
You should copy the definition of [script] from this pastie to avoid any corruption the forum may have introduce when I pasted the formula text into this message:
Pastie Database
https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=521

You should think of [script] as a default field like [Record ID#] or [Record Owner] as there is no good reason to not include it in every table by default.
You are probably marveling at this latest innovation in image onload technology. The truth is that we are introducing this new [script] technique to phase out the image onload technique and prepare you for the Service Worker technique which will use a similar naming convention for the injected JavaScript file.
Service Worker Game Changer (skip to 1 minute 15 secondes) https://www.youtube.com/watch?v=wl3kKBw-MGk&feature=youtu.be&t=1m15s
Photo of Tribs

Tribs

  • 20 Points
Dan, Thanks for all your innovations and hard work, I have used a lot of your feature and really appreciate your tips.

Regarding using gReqDBID+'_'+gDFID+'.js as the script name. I see a problem if you have to create a copy of the app or a new sandbox environment, the DBID's changes and the scripts won't load.

One other issue that I have not yet been able to resolve is to avoid the use of hard-coded table-IDs in my script, which needs to be changed every time I create a sandbox and change again before deployment.   If you have a solution for this that will be great.
Photo of Kp

Kp

  • 14 Points
gReqDBID, will this one work on mobile? I remember I  have error when use this on mobile, so I have to hard code table ID every time.
Photo of Kp

Kp

  • 14 Points
<img qbu='module' src='/i/clear2x2.gif' onload="if(typeof QBU=='undefined'){QBU={};$.getScript(gReqAppDBID+'?a=dbpage&pagename='+gReqDBID+'_'+gDFID+'.js&rand='+new Date().getTime())};">


guess if I place some variables infront of "$.getScript(gReqAppDBID", it should be able to be passed to js page.
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 30,044 Points 20k badge 2x thumb
> I see a problem if you have to create a copy of the app or a new sandbox environment, the DBID's changes and the scripts won't load.

That is generally true of any script solution. The application and  table dbid's (database dbids) will change in a copy of the application but the fid's (field ids), dfid's (form ids) qid's (query ids) etc will not. While it would be possible to add some additional script to dynamically look the dbid's up from the table names (which don't change with a copy) it generally isn't worth the extra effort. My solution is to float dbid's and other parameters up to the top of the script where they can be easily changed. Other data such as clists, slists etc may or may not be parameterized and I may even deviate from these self imposed "best practices" if I am in a hurry.

Regarding QuickBase's global variables (eg gReqDBID, gDFID etc) there are differences between the desktop and mobile but they are easy to fix. What would be great is if QuickBase got rid of these global variables altogether and just exposed the same data through some API or a single global object on every page:

var QB = {
  gJSdir: "js",
  gResDir: "https://assets.quickbasecdn.net/res/73823-18"
  gReqDBID: "bgcwm2m4g"
  targetParentDiv: "#mainBodyDiv";
  debugOnly: false,
  ...
}

While I am on this topic I should mention that you should avoid injecting your own global variables into QuickBase pages by wrapping all your inject code in a closure:

(function(){
  // your code here
})();

Also, the only global variable a user should use is QBU - this global variable is reserved for the QuickBase user and is used in the Image Onload Technique to prevent multiple injections of module.js when the [-] field is used in reports or grid edit pages. I get sloppy sometimes and do inject global variables but it should not be done in general.