Archive | September 2014

Setting the Maximum File Upload Size for an XPages Application

If you want to control the maximum value for an uploaded file, you can use the xsp.upload.maximumsize setting in

Application-Level Maximum Upload Size

There is no maximum upload set at the application level by default. (Although there is a server-level setting that I’ll come back to later in this post.)

To set it, you can use the Xsp Properties design element and set the Maximum size property under File Upload Options in the first column of the General tab. Specify the value in kilobytes (KB)


This adds the following value to the file (as seen on the Source tab):


Error Message

If you add an Error Message control for the File Upload control or an Error Messages control on the form, you will see an error message regarding the file size setting when you try to submit a form with an attachment that’s too large.


Server-wide Limit

As mentioned earlier, there’s no default at the application level. The default is the server-wide setting, which defaults to roughly 10 MB.

Even if you set the maximum at the application level, it can never exceed the server setting.

The server setting is defined on the Server document in the Domino Directory. It can be found on the Internet Protocols tab, HTTP subtab in the HTTP Protocol Limits section.


If you try to upload a file larger than the server-wide limit, it aborts the connection and throws an ugly error. (HTTP 500 – Internal Server Error)


Even if you set an application level maximum lower than the server maximum, if you try to upload a file larger than the server maximum, it will throw the same HTTP error.

Domino Usage Survey

As you may have already heard, PSC has posted a survey to gauge current usage and future direction for Domino.

If you haven’t already taken the survey, please take a moment and let us know how Domino is used in your organization. Please also share the link – the more feedback we get, the stronger the results will be.

The survey will be open until October 3rd and results will be posted publicly on October 6th.

Modifying an XSP Property fo a Single XPage

I’m familiar with setting XSP properties in at the application or server level and I’ve used tags to do the same within a theme, but I did not realize until recently that you can also set these properties at the XPage level to override the broader settings on a page-by-page basis.

Select the root tag for the page and go to All Properties in the Properties view. Under the data subtab, click on properties and click the plus (+) button to add a property.

This adds a new parameter and defaults the name attribute to param and the value attribute to val. In the source, it adds an tag containing an xp:parameter tag.

XSP Property Page Level - 1

Let’s see this in action with a few examples.

Here’s the first fiew lines of a brand new, unmodified XPage on my test server. The application leaves the server defaults for the HTML doctype and character set (although the latter is not visible in this output).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
<html lang="en">

If you want to add a meta tag to the page that displays the doctype and character set, you can add the xsp.html.meta.contenttype property to the page and set its value to true.

You can also override the HTML doctype and character set for the page with additional properties. (Click on the picture to enlarge.)

XSP Property Page Level - 2

Here’s the updated first few lines of output, including the meta tag and reflecting the updated doctype and character set:

<!DOCTYPE html>
<html lang="en">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

There are many more properties that can be modified at the page level (though not all of them). If you have the XPages Portable Command Guide, you can find them all described in depth there (The book covers through 8.5.3. Sven Hasselbach has a good post on some new properties that were added in Notes 9.)

It appears that you can similarly modify properties at the custom control level, but I have not tested the effectiveness or how conflicts are handled.

Allowing 0 Rows in a Repeat

The Allow zero rows in repeat controls setting in XSP Properties can be used to cause a Repeat control not to display any rows, giving you the ability to compute the row count as desired, even when there is data that would otherwise have been displayed. In this post, I’ll show how to update the setting and describe its effect.

XSP Properties

In Notes 9, you can find the XSP properties under Application Configuration in the Applications view of Domino Designer.


This UI gives you a nicer front end to modify a number of values in the file, which contains a lot of configuration information for the application.

There are 4 tabs, 3 of which contain several properties that you can modify and the fourth tab which displays the full source of the properties file.

There are many, many properties that can be set in the file, but there are only a few specified by default. The rest are treated as default values when not otherwise specified.


As you change properties in the UI, they will be added to the source.

Allow zero rows in repeat controls

The Allow zero rows in repeat controls setting on the Page Generation tab is not selected (i.e. false) by default.


The effect is that if you have a Repeat control where the rows property is computed to 0, it will revert to the default row count of 30.

If you select that option, it adds this line to


With this setting, you can compute a Repeat control’s row count to 0 and it will not show any rows. This effectively hides it from the UI, but still loads the repeat control into the JSF component tree so it can be modified programmatically, if necessary.


The XPages Portable Command Guide says that this property applies to View Panel, Data Table, and Repeat controls.

It works as expected with a Repeat control, but did not work properly with a View Panel in my testing (with Notes 9).

With the property set to false, a View Panel with the rows property set to 0 would show 30 rows. With the property set to true, the View Panel throws a divide by zero error.


Getting the Base URL of the Current Database with SSJS

It’s easy to get the current page URL in SSJS with context.getUrl().toString(). However, it’s a little less straightforward if you just want to determine the base URL of the current application. This can be useful when you need to build a link to some other page within the current application and send it out in an e-mail notification. In this post, I’ll look at the results of some methods in the XSPUrl object and show how to achieve the desired effect.

In the last post, I looked at URL @functions in the Extension Library. There are some useful functions there, but none that retrieve what I’m looking for.


The global context object has a getUrl() method that makes it easy to get a handle to an XSPUrl object representing the current URL. You can retrieve the full URL (including the querystring) or use any of the methods available to get pieces of the URL ( getAddress(), getHost(),getParameter(), getPath(), getPort(), getQueryString()).

Here are some examples of the output, given this url:

Method Result
context.getUrl().getPath() /BlogTesting.nsf/URL.xsp
context.getUrl().getSiteRelativeAddress(context) /URL.xsp

There are several handy methods, but none providing exactly what I’m looking for.

Options for Getting the Base URL

The getAddress() method gets the URL up to, but not including, the querystring. However, it still includes the current page name. The global view object has a getPageName() method that returns the name of the currently-displayed XPage.

The snippet that I’ve been using recently uses the getAddress() method and replaces the current page name with an empty string, leaving us with the base URL:

context.getUrl().getAddress().replace(view.getPageName(), '')

You could just as easily use Javascript’s substr or substring methods to look for the ‘.nsf’ and only retrieve characters up to the end of it in most cases, but that may be problematic if you have routing that masks the NSF name.

What’s Your Solution?

This seems like something that probably has a number of workarounds. How have you solved it? Is there something simpler that I’ve overlooked?


Check out David Leedy’s XPages URL Cheatsheet for more URL-related functions

There are two listed on there that sounded like they might provide what I was looking for, but did not.

  • database.getHttpURL() – includes the database replica ID rather than name and appends ?OpenDatabase to the end
  • view.getBaseURL() – sounds perfect, but doesn’t return anything

URL @Functions in the Extension Library

There are a few @Functions for working with URLs available in the Extension library. They can come in handy if you need to work with URLs related to any element in your database.


These functions are part of the extension library. They’re available if you’ve installed the Extension Library, or if you have Upgrade Pack 1 for 8.5.3. They’re also part of the extension library features built directly into Notes9.


The functions are available on the Reference tab in the SSJS Script Editor. Under Libraries, select @FunctionsEx to see the additional functions.

ExtLib URL Functions - 1

The following URL functions are available:

  • @EncodeUrl() – Encodes spaces and symbols in the URL
  • @FullUrl() – Displays the full path to a resource in the database (relative to the server)
  • @AbsoluteUrl() – Displays the absolute path to a resource in the database*
  • @IsAbsoluteUrl() – Boolean value for whether a given URL is absolute


Here are some examples of how they can be used in an application:

Code Result
@FullUrl(view.getPageName()) /BlogTesting.nsf/ExtLibURLFormulas.xsp

Where the url is: and $ymbol$
@IsAbsoluteUrl(view.getPageName()) false
@IsAbsoluteUrl(context.getUrl().toString()) true


I generally use context.getUrl() and work with that to parse and build URLs, so I haven’t run into this before, but the output of @AbsoluteUrl() wasn’t what I expected. At first glance, it appeared to give the full url to the specified design element, but it actually just gives the protocol, server, and design element name that was supplied.

It looks like I can get the real absolute url to the design element by combining @FullUrl() with @AbsoluteUrl()

Code Result

XPages Tip: Getting the Value of the Current Field with SSJS (@ThisValue equivalent)

Sometimes, I miss the convenience of several @functions. If you’re writing SSJS code that needs to access the value of the current field from an event handler on that field, but you don’t want to hard-code the component name (so you can easily reuse it), it would be handy if there was an @ThisValue equivalent. Alas, there isn’t, but, fortunately, you can still easily access the value.


The special this keyword is where we need to start. It provides a handle to the current object.

When running code from an event handler, the object type is:

I find this by using the typeof operator in JavaScript

print (typeof this);


The event handler doesn’t have a value — we need to get to the parent component that contains it. That’s where the getParent() method comes in handy. As you would expect, it goes up the chain and gives us a handle to the parent object, which for my sample input field is:

This object has a getValue() method to return the value of the component.

Getting the Current Field Value

Putting this together, I can easily get the value with this line:

var thisValue = this.getParent().getValue();

FYI — if you want the ID of the parent control from an event handler, you can use this line:

var thisID = this.getParent().getId();