XPages ND9 (Dojo 1.8) does not work with other AMD loaders (and the work around)

Today I took a new jQuery plugin that I was playing with from an R8.5.3 environment where it worked, to an R9 environment and it failed – I figured it had something to do with something I had been reading about over the last month and in fixing my problem this lead to a more serious realization that I KNOW other people are also going to come across.


A brief scan of the last month’s discussions on Xpages and jQuery Mobile 1.3 reveals a number of posts started by Dave Leedy regarding the use of IBM Notes Domino 9 and jQuery Mobile 1.3





What’s going on?

I saw the following Tip from Sven Hasselbach (very smart man!) on Dave Leedy’s blog post

Looks like an AMD loader problem with Dojo & JQM. I have tried out to disable the Factory scan in a test page and this worked for me. To do this I have added the following parameters in the xsp.properties:

xsp.client.script.dojo.djConfig=dojo-amd-factory-scan: false

Maybe this can help you with your problems in ND9.

This lead me to this bug report


make dojo work with other AMD loaders

Which then lead me to the realization that this is a bigger issue than just JQM 1.3 and I solved my problem and here is how.

Solution (ND9)

Within the Package Explorer  (Window—open perspective –> xpages) in the WebContent folder for your database you will find the xsp.properties file (as described http://heidloff.net/home.nsf/dx/06172011015521AMNHE8Y7.htm)


Click to open the Source Tab

and enter the following

xsp.client.script.dojo.djConfig=dojo-amd-factory-scan: false

And Save – that’s it


If you look at the source code of the created XPage you will see that the new parameter has been added to the script tab creating the dojo.js as a djConfig property


doing a quick search explains what this property does


“For example, we could disable the amd factory scan (scanning the module for CommonJS require(module) statements to load as deps) with…”

Not only does that solve the problem with jQuery Mobile, it also solved my problem with the jQuery Table plugin which I wanted to use, which used require.js to load the jQuery dataTable plugin.


thank you Sven Hasselbach (again!)


12 thoughts on “XPages ND9 (Dojo 1.8) does not work with other AMD loaders (and the work around)

  1. Has anyone got this working?

    When I add the above mentioned line in the xsp.properties file, dojo stops working and firebug throws this line:

    SyntaxError: missing : after property id
    ({ locale: ‘de’, dojo-amd-factory-scan: false }) xspClientDojo.js (Zeile 4, Spalte 21)

    Seems that the dash (-) cannot be interpreted as a parameter.

    Am I missing something here?

      • Hello, thank you for the answer.

        I’ll give that a try.

        But to be more precise, dojo stops working in all browsers and also in XPiNC as I need to load (multiple) dependent plugins in jQuery.

    • Pantelis,

      I saw this error in R8.5.3 (I think because the version of dojo is lower) – which is a pain because in my local environment (8.5.3) I have to remove the tag from the xsp.properties and then add it back when replicating to the main server.

      But on the R9 server, in firefox, I do not receive the error you are listing. Firefox 21 Firebug 1.11.4 (updated this week)

      When you view the source on the webpage it should look like this


      • Hello Mark,

        thanks for coming back quick on this topic.

        I could come around this issue by following the instructions given by Sven.
        I had to rearrange all javascript and css files that were depending on the jQuery-libraries (and there respective plugins) as “xp:headTag” resources.

        After that, XPiNC was able to load the jQuery components correctly. To ensure cross-referencing resources (like images from css files) I had to prepend this SSJS-Function on every href/src parameter within the xp:headTag attributes (otherwise the XPiNC can not find the elements):

        function getBaseURL(filePath) {
        server = session.createName(database.getServer());

        var baseURL = database.getFilePath().replace(“\\”, “/”);
        if(@ClientType().toLowerCase()==”web”) {
        return (“/” + baseURL + “/” + filePath);
        } else {
        return (“/xsp/” + server.getCommon() + “!!” + baseURL + “/” + filePath);

        I tried to extract the resource files as they will need to be used in other applications too, but XPiNC is a pain when referencing resources on the server. So far I haven’t found any way to have commonly used resource files on the server (like css, images, scripts, jQuery-libs and plugins) running also in XPiNC. The solution now has all the resource files wihtin the applications (what a f*reaking mess, when there is one css change necessary).

        Thanks again for your help.
        Also thank you Sven for pointing me to the right direction.


      • Interesting point about XPiNC – because it is designed to be able to run offline – you would have to have the resources in the databases at all times regardless. The other option is to use an OSGI plugin and have the resources available locally to the machine for all XPiNC databases – at least then you only have to update one file locally – but agreed P I T A 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s