Gridx in XPages – 5: Modularizing Common Resources

The second post in this series showed how to use the djConfig property to make the Gridx (or any other library’s) resources available to an XPage. Looking forward, I wanted to find a way to modularize the common resources required by Gridx so they do not need to be included on every XPage. In this post, I’ll describe the challenges and then show a much cleaner solution that I found that makes it easy to reuse the resources.

Gridx Series

Gridx in XPages — Entire Series

Modularization Challenges

I thought it would be pretty straight forward to move the style sheets, djConfig property, and beforePageLoad code to define the modulePath to a custom control and reuse it across any pages that display a Gridx grid. Unfortunately, it wasn’t that simple.

The style sheets and the beforePageLoad code worked fine from a separate custom control, but the djConfig property only worked when on the XPage. This would still be an improvement in reusability, but would require setting that property on all XPages that display a grid.

I then thought that I could set the djConfig property in the application’s XSP properties. While that works for other djConfig attributes, it does not work for modulePaths because it still has the same escaping problem that necessitated the beforePageLoad code to begin with.

Dojo Module Path Resource

Fortunately, I found a much simpler solution – a Dojo Module Path Resource!

It’s a page-level resource, just like a style sheet, script library or Dojo module. It makes it much simpler to reference the Gridx code within the application.

  1. From an XPage or custom control, go to the Properties view and select the Resources subtab.
  2. Click the Add… button and select Dojo Module Path Resource…
  3. Enter gridx as the prefix and /gridx as the url

Gridx 5 - Dojo Module Resource

This tells the page to look for a module named gridx at the location /gridx. The forward slash starts from the WebContent folder in the application and we put the code into a folder named gridx. (Adjust as needed if your directory structure is different.)

This is much simpler; it removes the need for the djConfig property and the beforePageLoad code!

Common Gridx Resources

Unlike the djConfig property, specifying a Dojo Module Resource Path works from a custom control included on a page, so now we can separate the common resources into a custom control for easy reuse.

Now, I have a custom control named ccGridxResources. This is the full source:

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="">

    <!-- Claro Theme -->
    <xp:styleSheet href="/.ibmxspres/dojoroot/dijit/themes/claro/claro.css"></xp:styleSheet>
    <xp:styleSheet href="/.ibmxspres/dojoroot/dijit/themes/claro/document.css"></xp:styleSheet>

    <!--  Module Path to locate Gridx Library -->
    <xp:dojoModulePath url="/gridx" prefix="gridx"></xp:dojoModulePath>

    <!-- -Main GridX Stylesheet  -->
    <xp:styleSheet href="gridx/resources/claro/Gridx.css"></xp:styleSheet>

Line 10 is the Dojo Module Path Resource that specifies where to find the files. The rest are the 3 stylesheets that we were already including. The djConfig property and beforePageLoad code are no longer required.

Streamlined XPage to Create the Grid

Now, this is the full source of the XPage required to create the same grid as the last post, accessing live data via a REST service.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="" xmlns:xc="">


<div id="gridX_Here" style="height:300px; width:300px;"></div>

    "gridx/Grid", "dojo/store/JsonRest",
    "gridx/core/model/cache/Async", "dojo/domReady!"
  ], function(Grid,JsonRest, Cache) {

    var store = new	JsonRest({
      idProperty: '@noteid',
      target: "X_REST.xsp/gridData"

    var columns = [
      {id: 'first', field: 'firstname', name: 'First', width:	'70px'},
      {id: 'last', field: 'lastname', name: 'Last'},
      {id: 'state',field: 'state', name: 'State', width: '40px'}

    grid = new Grid({
      id: "my_gridX",
      cacheClass: Cache,
      store: store,
      structure: columns

    //Put it into the DOM tree.


Now we have a more modular design and a simpler page structure to work with as we get ready to add features to the grid.


11 responses to “Gridx in XPages – 5: Modularizing Common Resources”

  1. Csaba Kiss says :

    Now, this looks much better than the awful beforePageLoad script.

  2. vincentdemare says :

    You can replace line 17
    target: “X_REST.xsp/gridData”
    target: “#{javascript:view.getPageName()}/gridData”

    • vincentdemare says :

      A little correction :
      target: “#{javascript:view.getPageName()}/gridData”.substring(1)

      • Brad Balassaitis says :

        That will definitely work if the REST service is on the same page as the grid (and if it’s within an xp:script block). I generally put them on a separate page.

  3. Ilya says :

    Sory for my English. =)
    Help get rid of the error “Uncaught ReferenceError: require is not defined”.
    Thank you.

    • Brad Balassaitis says :

      Uncaught Reference Error can be thrown for just about any client-side JavaScript error code in a grid. If the error really is related to the require module not being available, then you may be using an older version of Dojo (which changes with each Domino version and fix pack) that wasn’t designed to use AMD-style loading. If that’s the case, you would need to load the Dojo modules manually on the page as individual page resources (or at the theme level).

Leave a Reply

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

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

Google+ photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s

%d bloggers like this: