Archive | August 2014

XPages Tip: Select a Working Set in Package Explorer (and Navigator)

If you’ve been using Domino Designer for any length of time, you’re likely aware that you can group your applications into Working Sets in the Applications view. But did you know that you can do the same thing in the Package Explorer and Navigator views?

Working Sets in the Applications View

Here’s what it looks like to select a working set in the Applications view in DDE:

Blog - Package Explorer - 1

You can choose one or select the Multiple... option to select multiple working sets.

Working Sets in the Package Explorer View

Until recently, I didn’t realize that I could make a similar selection in the Package Explorer view. I always just saw it as annoying that I had to dig through every NSF I’ve worked on until I looked around for this option.

If you click on the icon with 3 horizontal gray lines, you get this drop-down:

Blog - Package Explorer - 2 - None Selected

You can select a single working set or choose the magic Window Working Set option to have the Package Explorer databases automatically updated based on your working set selection in the Applications view.

Blog - Package Explorer - 3 - Window Working Set Selected

If you want to disable this option and show them all, you can select Deselect Working Set from the menu.

Working Sets in the Navigator View

Interestingly, you can also choose a working set in the Navigator view, but the options are more limited; there’s no option to link it up with the current working set.

Blog - Package Explorer - 4 - Navigator

Advertisements

XPages Tip: Fixing a partial refresh issue with the Pager Add Rows control in a Data View

I came across a strange issue with a Data View using a Pager Add Rows control resetting the number of documents displayed after a partial refresh. In this post, I’ll explain the scenario where I saw the issue and show the simple solution that fixed the problem.

The Problem

I have a Data View that starts with 20 rows and uses a Pager Add Rows control to add 10 more rows at a time.

Within the summary facet, there’s an action that can take place, which runs a minimal script and then performs a partial refresh with partial execution on the summary section.

This *seems* to be fine when performed within the first set of rows, but I noticed that if additional rows are added to the display and then the action is run in any one of the rows, the action runs successfully, but the data view is reset to only display the initial set of 20 rows.

If the action was taken on a row after the initial 20, I can add rows again and see that the action has taken place and the partial refresh has occurred as designed.

The Fix – Changing the ‘State’ Property

I tried making a number of changes to partial refresh and partial execution settings, but none of them fixed this issue.

Ultimately, the issue was fixed by a simple property change. The Pager Add Rows control has a state property (All Properties > basics > state)

When set to true, it stores the view state on the server.

Pager Add Rows - State Property

This did the trick. It allows the row count to be preserved between partial refreshes by storing it on the server.

Monitor Source Control Synchronization with the Console View in DDE

If you’d like to monitor the synchronization of an application with the local source control repository, you can use the Console view in Domino Designer. In this post, I’ll show different kinds of helpful information that the view displays.

Console View

If you’re using source control, the Console view displays information about the synchronization of design elements between the NSF and the (source control) on-disk repository.

This can be helpful to see what’s going on if your DDE client is responding slowly (and may help you decide whether you want to enable or disable automatic synchronization). It may also be helpful in tracking down the creation of the dreaded .orig files.

Opening the Console View

Select Window > Show eclipse views > Other...

Blog - Console Sync - Add 1

Under General, select Console

Blog - Console Sync - Add 2

Console Output

When you open an application in DDE, you’ll see the console start the synchronization process. (There’s even a misspelling to keep the grammar cops on alert.)

Console - Show initial synch

When you update an existing design element, you see that it exports the change to the on-disk repository (for the .xsp and related .xsp-config file).

Console - Show Element Modified

When you add a new design element, it creates the .xsp, .xsp.metadata, and .xsp-config files in the on-disk repository.

Console - Show Element Added

Automatic Synchronization

If you have automatic synchronization enabled, it will happen when the application is built. (If you have Build Automatically enabled, it will happen automatically. Otherwise, it’ll happen when you build the application.)

These two properties in the Domino Designer preferences determine whether synchronization is automatic:
Console - DDE Prefs - Auto Sync

 

Simple Sync Conflicts

If you’ve seen a popup like this, then there is a synchronization conflict:

Blog - Console Sync Conflict

Here’s the corresponding message in the Console view:

Nsf file AppProperties/database.properties and disk file AppProperties/database.properties both have been updated since last sync or are never synced:Wed Aug 20 20:17:36 EDT 2014

It indicates a conflict and it’s making it easy for you to choose how to resolve it. You can also see evidence of this in the Console view. I tend to see this often with the database.properties (because the time stamps are always being modified). This type of popup is displayed when you synchronize with source control before opening the application in DDE. (If you modify the same element as someone else, conflicts will show up differently when you try to commit changes within your source control plugin or application.)

One View – Multiple Uses

The Console view is displayed as Console (DDE Sync Console) when displaying source control sync information. You can also switch it to be used as a Java stack trace console by via the Display Selected Console icon.

Computing Custom Date Format Patterns Throughout an Application

If you want to ensure consistency in date formatting throughout your application, you can define the pattern for each Edit Box or Computed Value control that displays a date. What you may not have considered is that you can compute the date format, so you can define it in one place and use the same format everywhere. In this post, I’ll show how you can set it up and even change it conditionally.

Locale Conversions

The browser will automatically attempt to format dates based on your specified locale. Here’s an example of a computed field set to display a date. The Display type must be set to Date/Time.

Date Format 1a Default Date Format - Settings

Here’s how it displays in my browser when the language is set to English:

Date Format 1b Default Date - English

Here’s how it displays when I change my browser language to French:
Date Format 1c Default Date - French

Custom Date Patterns

If you want to change the default formatting, you can define a custom date format pattern.

To define a specific pattern, change Display format to Custom and then you can edit the Pattern field. (You can select a pre-defined pattern or enter your own.)

Date Format 2 - Custom Date Format

In this case, the pattern will stay the same, regardless of the browser language.

(Note: When defining a date pattern, the month value uses one or more capital M’s, because the lower case m is for minutes when defining a time pattern.)

Computing Date Patterns

Just like most other properties in XPages, there’s a blue diamond next to the Pattern field, allowing you to use SSJS to compute it. This gives you the opportunity to create a library function to return some pattern to use. Then, you can set all of your date controls to call the same function and modify the pattern in one place.

Your library function could be as simple as this:

function getDateFormat() {
  return 'dd-MMM-yyyy';
}

Taking it one step further, you could add logic in the function to conditionally determine the pattern, whether it be based on a user preference or a locale or just changing date formatting patterns on a daily basis because you like to mess with your users.

If you use more complex logic, you may also want to consider storing the pattern in an applicationScope variable, so it’s available throughout the application.

function getDateFormat() {
  if (!applicationScope.dateFormat) {
    // Logic to determine date format
    applicationScope.put('dateFormat', some_date_format);
  }

  return applicationScope.dateFormat;
}

Computation Timing

The default setting for the logic Compute Dynamically (#). If you leave it that way, it will throw this error when you load the page: The value of the property pattern cannot be a run time
binding.

To fix this, select Compute on Page Load when entering/editing the snippet or change the octothorpe/pound sign/hash (#) to a dollar sign ($) in the page source, because date pattern computations only work on page load.

Compute Date Formats - 3

Quick Replace

If you’ve already set up hard-coded patterns on date fields, they would look something like this:

You can do a quick search and replace to modify them all easily.

Search for:

pattern="dd-MMM-yyyy"

Compute Date Formats - 4a

Click the Replace... button rather than the Search button.

Then replace with:

pattern="${javascript:return getDateFormat();}"

Compute Date Formats - 4b

XPages Tip: Control Declaration Snippets

Control Declaration Snippets give you an easy way to retrieve a properly-typed handle to an XPages control on your page. In this post, I’ll show how to use them and why they are beneficial.

Control Declaration Snippets

From the SSJS script editor, Control Declaration Snippets is one of the Libraries: options on the Reference tab.

It displays an alphabetized list of controls on the page.

ControlDeclarationSnippets1

Double-click any one to insert the control declaration snippet into your script.

This screen shot shows the result of adding snippets for all 7 controls on my sample page:

ControlDeclarationSnippets2

Benefits

This is a convenient way to save a few keystrokes in setting up a handle to a control on your page, but that’s not the only benefit.

Normally, when you set up a variable for a handle to a control, you don’t enter the full data type of that control. Control declaration snippets do that for you. The big advantage is that typed variables provide better typeahead.

Take, for example, these two lines, which accomplish the same thing:

var myInputText = getComponent("inputText1");
var inputText1:com.ibm.xsp.component.xp.XspInputText = getComponent("inputText1");

If you type myInputText. you’ll get some typeahead options because the editor knows that you’re dealing with a some component.

ControlDeclarationSnippets4

However, if you type inputText1. you’ll get many more typeahead options (including event handlers) because the editor now knows exactly what type of component that you’re working with.

ControlDeclarationSnippets3

Set Focus on a Field when Showing a Bootstrap 3 Modal

While testing an application that I’m working on, I noticed that the focus is not set on a field within a Bootstrap modal when it’s shown. This is annoying to the user because it requires to tab a number of times (since the focus stays on the button clicked to show the modal) or click into a field in order to start typing. In this post, I’ll show how to force the focus to be set on a specific field when a modal is shown.

Event Delegation

One simple approach is to use jQuery event delegation (here’s a great explanation from Mark Roden). An event handler can be added to the body tag to fire whenever a modal is shown. Within that handler, we can set the focus on a specific field.

$('body').on('shown.bs.modal', '.modal', function () {
  $('[id$=myField]').focus();
})

The first line sets up the event delegation by adding a listener to the body of the page for the event of showing a modal (shown.bs.modal). The second line locates the field named myField and sets focus on it.

The selector in the second line may look a bit strange, but it’s effect is to find the element where the id attribute ends with myField. This is because XPages adds a number of colon-separated prefixes to each element, depending on it’s depth in the page structure. In order to not worry about all of that, the code looks for the element that ends with the name that I assigned to the field.

Here are two other options that you have for achieving the same effect:

  1. Add a unique class name to the field and use $(‘.yourClassName’) as the selector
  2. Use Mark Roden’s x$() function to select an element

Modals and Partial Refreshes

As if there haven’t already been enough (too many?) references to Marky, take a look at this post if you have a modal that needs to perform partial refreshes.

Ultimately, the code I’m actually using in my application looks like this:

$('body').on('shown.bs.modal', '.modal', function () {
  $('FORM').append($('.modal'));
  $('[id$=myField]').focus();
})

Multiple Modals

This method works fine on a page that only has one modal. If you have multiple modals, you’d need to adjust the logic in order to set the field focus as desired. One more generic option would be to change the jQuery selector to just find the first input field on the modal.

XPages Tip: Disabling Required Validation in a Dojo Filtering Select

Dojo Filtering Select (xe:djFilteringSelect) controls include client side ‘required’ validation by default. The problem is that if it fails this validation, any page submission or other server-side action will not be triggered. However, if you want to disable this validation, the built-in property of the control doesn’t work. In this post, I’ll show how to achieve the desired effect.

Creating a Filtering Select

If you’re not familiar with the Dojo Filtering Select, take a look at this post.

Validation Behavior

Take, for example, the Dojo Filtering Select that I used in a recent post about changing the search behavior of a Dojo Filtering Select:

FilteringSelect_Required-1

If I clear the value in the field and tab out of it, I am presented with this error message: ‘This value is required’

FilteringSelect_Required-2

The problem is that any server-side onChange error handler of the field will not fire because the field failed client-side validation.

Disabling the Required Validation

The Dojo documentation shows that adding a required attribute and setting it to false will disable this behavior.

There’s a required property on the djFilteringSelect control. Unfortunately, it has no effect when set to false.

If you look at the HTML output, you’ll see that the field has this attribute: aria-required="true"

To get it to work, you can add the required attribute (and set it to false) as a Dojo attribute.

FilteringSelect_Required-3

This does the job and it changes the attribute in the HTML output for the page to: aria-required="false"