Two exceptional conditions may arise when loading resources using link and script elements, which is that the desired resource may not exist, or that it exists but may be malformed (i.e. it has a syntax error). In principle, and under either of these conditions, the browser should call the onerror event-handler (if present) for the object in question.
AJS_ODL provides a handler for this event (for both element types), execution of which causes the execution of any function that you provide as the onError handler in the LoadDef in question. However, we live in the real world, and so (sadly) support across the browser spectrum, and through the various versions of each browser varies. Given this, and given the platform on which AJS_ODL finds itself running, you may find that your error handlers do not execute under exceptional conditions.
You can find an extensive and very useful comparison-chart on https://pie.gd/test/script-link-events/. This shows the variance among the major browers at a glance.
Despite this problem, do note that, in respect of the IMG, LINK and SCRIPT loading-methods, AJS_ODL removes its event handlers from the HTML element-object concerned once the loading transaction has terminated (successfully or in error). This means that AJS_ODL has nothing more to do with those elements subsequently, and that client-code is therefore free to do what it wants with them, including assigning new event-handlers.
Browser and Event-Handling
Script-Tag Hack Drawbacks
Aside from patchy support for the onerror handler, the use of script-element injection carries a sizable number of drawbacks, some of which are serious. These are as follows:
Given that AJS_ODL allows the application of multiple LoadDefs to a given object (which, collectively, may load a mix of resource types), and given the inherent asynchrony of network communications, the problem of race-conditions may arise.
Consider the two UML sequence-diagrams. In the first, AJS_ODL issues a request for an image-object, followed closely by a request for some code that, when it arrives, is evaluated and executed, at which point it performs an operation of some sort on the image object.
Given that the two resources arrive at the client in the order in which they were requested, all is well. However, the code request and the image request are in a race with each other, and the second diagram shows a different outcome, where the code arrives before the image. This is disastrous because the code then attempts to operate on an image object that has yet to enter the execution environment.
The only way to ward-off such problems is careful application-design, and do note that AJS_Logger may be of value here in tracing the sequence of events that lead to this kind of trouble. Similarly, AJS_Validator can assist also, in that it allows you to place guards upon the execution of one or more methods, such that unsatisfied conditions at the time of invocation of those methods cause a run-time exception.
Note also that, if this kind of problem arises through the use of two SCRIPT LoadDefs, a solution is to use some form of event marshalling such that execution of retrieved-code occurs only when all interdependent elements have arrived on the client platform (and a small, free library that is dedicated to such things is available on dodeca.co.uk). Alternatively you can use the asynch attribute with a value of false, as this will force the browser to evaluate scripts only in the order in which loading requests are issued, although this is available only in HTML5-compliant browsers.
Note that, in such scenarios, and where a given XHR retrieval fails, AJS_ODL will flush its queue of pending XHR-requests (i.e. pending requests are not dispatched).
Security is an ever-present concern in modern web-sites and -applications, and you should note that AJS_ODL constitutes only a range of options for implementing the automatic retrieval of resources. It provides no inherent security checks or mechanisms – it is simply a retrieval framework – and this means that, when you employ AJS_ODL in your applications, you must be aware of the potential exploits that are available to blackhat developers. This is your responsibility alone, and does not fall within AJS_ODL's remit.
Note also that the very appeal of AJS_ODL – that it can make things appear within the execution environment automatically and transparently – adds to our concerns here, in that it make it easy to forget that an on-demand loading mechanism is in place. In principle, this can make it easier to expose security holes to an attacker inadvertently, and the only genuine solution to this is relentless vigilance on your part.
If you are working on a security-sensitive application, you should avail yourself of the Open Web-Application Security Project, which details exhaustively the loopholes that attackers can exploit, and which provides a wealth of information on how to guard against such nefarious practices.