REFERENCING WEB SERVER FILE SYSTEM RESOURCES IN XPAGES

I’m getting ready to start blogging about some Dojo hotness in XPages. IBM saw fit to include the Dojo 1.1.1 toolkit in the Domino 8.5 distribution, but unless your native XPage widget is calling the resources you’re out of luck if you want to access the toolkit's resources yourself. In general terms, how do you access a resource that’s on your server’s file system? You see, if you try to put a resource’s relative URI into an XPage’s resource list, Domino will prepend the path of the current database (er, application) -breaking the URI. You COULD specify the absolute URI of the resource’s href property, but that kills your app’s portability. You can also specify the link in straight HTML, but that won’t guarantee it gets loaded in the document’s header or –generally- in the order you may require. The hack is to drill into the resource's properties and toggle the value as computed. (See image.)

resource href properties in XPage

Then you take advantage of the handy-dandy facescontext object exposed by the ServerSide Javascript engine to ferret out the current context’s server name and protocol to build your URI on the fly:

  1. request = facesContext.getExternalContext().getRequest();
  2. server = request.getServerName();
  3. protocolFull = request.getProtocol(); //returns protocol/version (ex: HTTP/1.1)
  4. protocolOnly = protocolFull.split("/")[0]; //get just the protocol (lowercase it in next step...)
  5. protocolOnly.toLowerCase() + "://" + server + "/domjs/dojo-1.1.1/dojo/resources/dnd.css"

Note that for your edification, this example is more verbose than it needs to be. An added benefit of being able to directly reference resources such as CSS on the file system is to utilize the images said CSS may itself reference. The alternative being to import the CSS, any and all images you require that the CSS file references and repoint the relative URI’s as needed.

HAT TIP to the XPages wiki article Accessing Servlet objects in XPages using the FacesContext and to David Leedy for taking time from his busy IAMLug schedule to patiently offer me workarounds.