How robust in the [iol] or ""image on load"" technique?
Since i am using this technique to administer some important data, I was just curious how certain this technique will load the javascript. Will future Quickbase updates cause this to break?
Forum Discussion
Ok we are on the same wavelength ..
But counterpoints:
(1) In any risk assessment you have to look at risk and reward. The rewards of using JavaScript are unending with QuickBase. There has been a literal explosion of features and affordances JavaScript brings to the browser to the point where senior developers can't keep up and the pace of innovation shows no signs of slowing down. Products such as QuickBase can't keep up with the pace of innovation and quite frankly most software companies can't find enough developers versed in the latest technologies and their products to some degree or another are laden with lots of technical debt. Using script with QuickBase allows you to workaround almost any conceivable limitation or problem and can utilize the benefits of new technology immediately without waiting for hardcoded features to be prioritized and implemented. If you don't use script you are simply locking yourself out of the enormous benefits that it can provide.
(2) The computational (ie formulas) and workflow model of QuickBase has to evolve and it needs to embrace script. The idea of stringing together URLs that redirect with 302 response status codes using redirection parameters is outdated. The existing QuickBase user base may be comfortable with the idea that the URL action represents the "state" of the application but this model has been abandoned by the development community in favor of single page application (and other architectures) that perform computation, workflow and state management through background AJAX calls - not by constantly reloading the full page and displaying a new URL.
(3) When I write custom scripts I go out of my way to not interfere with QuickBase's native features. One technique I encourage is to prevent namespace collisions by always placing your code in a closure and prefixing any element id, variable or class with a "QBU" prefix if they will be exposed at global scope. Another technique is to emulate user input rather than directly modify the DOM. Or to mutation observe changes in QuickBase's modification of the DOM. Some of these topics I mention may be over many peoples heads but I put a lot of thought into how to safely use script with QuickBase. Quite frankly if over 15 years I have never had a problem that could not be fixed often in several different ways.
(4) Webhooks and Actions can only respond to a limited set of events (add, edit delete a record) and they do so server-side. In contrast all events are initiated client side and include 1000s of different events. Script gives you the ability to respond to any of these client side events immediately and without latency. Webhooks are best at responding to events generated from a foreign domain.
But counterpoints:
(1) In any risk assessment you have to look at risk and reward. The rewards of using JavaScript are unending with QuickBase. There has been a literal explosion of features and affordances JavaScript brings to the browser to the point where senior developers can't keep up and the pace of innovation shows no signs of slowing down. Products such as QuickBase can't keep up with the pace of innovation and quite frankly most software companies can't find enough developers versed in the latest technologies and their products to some degree or another are laden with lots of technical debt. Using script with QuickBase allows you to workaround almost any conceivable limitation or problem and can utilize the benefits of new technology immediately without waiting for hardcoded features to be prioritized and implemented. If you don't use script you are simply locking yourself out of the enormous benefits that it can provide.
(2) The computational (ie formulas) and workflow model of QuickBase has to evolve and it needs to embrace script. The idea of stringing together URLs that redirect with 302 response status codes using redirection parameters is outdated. The existing QuickBase user base may be comfortable with the idea that the URL action represents the "state" of the application but this model has been abandoned by the development community in favor of single page application (and other architectures) that perform computation, workflow and state management through background AJAX calls - not by constantly reloading the full page and displaying a new URL.
(3) When I write custom scripts I go out of my way to not interfere with QuickBase's native features. One technique I encourage is to prevent namespace collisions by always placing your code in a closure and prefixing any element id, variable or class with a "QBU" prefix if they will be exposed at global scope. Another technique is to emulate user input rather than directly modify the DOM. Or to mutation observe changes in QuickBase's modification of the DOM. Some of these topics I mention may be over many peoples heads but I put a lot of thought into how to safely use script with QuickBase. Quite frankly if over 15 years I have never had a problem that could not be fixed often in several different ways.
(4) Webhooks and Actions can only respond to a limited set of events (add, edit delete a record) and they do so server-side. In contrast all events are initiated client side and include 1000s of different events. Script gives you the ability to respond to any of these client side events immediately and without latency. Webhooks are best at responding to events generated from a foreign domain.