Asked  7 Months ago    Answers:  5   Viewed   25 times

I have a dynamic web page where I need to import an external JS file (under an IF condition) inside another javascript file.

I tried to search for a feasible solution but it didn't work.

I have tried loading a JS file to the DOM using document.createElement() but it also didn't work. Apparently the Js was loaded into the DOM but was not accessible in the current JS file.

Solution in jQuery will also be fine



jQuery's $.getScript() is buggy sometimes, so I use my own implementation of it like:

jQuery.loadScript = function (url, callback) {
        url: url,
        dataType: 'script',
        success: callback,
        async: true

and use it like:

if (typeof someObject == 'undefined') $.loadScript('url_to_someScript.js', function(){
    //Stuff to do after someScript has loaded
Tuesday, June 1, 2021
answered 7 Months ago

You may also checkout the UI.Layout jQuery plugin. Here's a demo.

Sunday, August 8, 2021
Scott Chantry
answered 4 Months ago

The easiest way short of a JS library is to make an XMLHttpRequest and eval() the return. Your "onload" would be when the data is returned, and "oninit" would be right after you've eval'd.

EDIT: If you want to sequence this, you can create an AssetLoader that takes an array of scripts and won't eval() a script until the one preceding it has been fetched and initialized.

EDIT 2: You can also use the script.onload stuff in the post referenced in the comments. The eval method has a slight advantage in that you can separate and control the load and execution portions of the script import.

EDIT 3: Here's an example. Consider a file called foo.js that contains the following:

function foo () {

Then execute the following from another page in your browser:

function initScript (scriptString) {

function getScript (url, loadCallback, initCallback, callbackScope) {

    var req = new XMLHttpRequest();'GET', url);

    req.onreadystatechange = function (e) {

        if (req.readyState == 4) {
            if (loadCallback) loadCallback.apply(callbackScope);
  , req.responseText);
            if (initCallback) initCallback.apply(callbackScope);




function fooScriptLoaded () {
    alert('script loaded');

function fooScriptInitialized () {
    alert('script initialized');

window.onload = function () {
    getScript('foo.js', fooScriptLoaded, fooScriptInitialized, null);

You will see the alerts "script loaded", "script initialized", and "bar". Obviously the implementation of XMLHttpRequest here isn't complete and there are all sorts of things you can do for whatever scope you want to execute the script in, but this is the core of it.

Tuesday, August 24, 2021
rob mayoff
answered 4 Months ago

As I tried out and read through the link given by @konrad, I found that its a bug in Jquery UI - even in the latest version of it. The problem got solved as soon as I started using Jquery UI 1.9.2 version

here is the updated fiddle:

with same code:

var zindex = 10; 
    containment: "body",
    scroll: true,
    revert: function (event, ui) {
        $(this).css("border", "none");
        return !event;
    start: function (event, ui) {
        $(this).css("z-index", zindex++);
        $(this).css("border", "2px solid #333");

    hoverClass: "over",
    drop: function (event, ui) {
        $("<li class='item'></li>").html(ui.draggable.html()).appendTo(this);

It uses Jquery version 1.9.2 from

Wednesday, August 25, 2021
answered 4 Months ago

It seems like OSGi is exactly what you're asking for. It can be complex, but there are ways to deal with that. Some of the complexity can be mitigated by using SpringDM or something similar to handle the boilerplate tasks of registering and consuming services in the runtime. Annotation-driven service registration and dependency injection really reduces the amount of code that needs to be written.

Another way to reduce complexity is to deploy the bulk of your application in a single bundle and only deploy the parts that need to be modular into their own bundles. This reduces your exposure to registering and using services from other bundles in the runtime as well as reducing the complexity of deployment. Code running within a bundle can use other code in the same bundle just as in a standard Java app - no need to interact with the OSGi runtime. The opposite of this approach is to break up your application into lots of discrete bundles that export well-defined services to other bundles in the system. While this is a very modular approach, it does come with extra complexity of managing all those bundles and more interaction with the OSGi runtime.

I would suggest taking a look at the book "OSGi in Action" to get a sense of the issues and to see some decent samples.

Thursday, September 23, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :