Java and Selections Part Five: Value Pickers Solution

Home » Java and Selections Part Five: Value Pickers Solution

So we’ve added our Value Picker to the XPage, bound the component to an Edit Box or Dojo List Text Box or some other control that’s bound to a field on a Notes Document or viewScope variable. Now we’re ready to go.

A dataProvider for a Value Picker needs to implement the Java class com.ibm.xsp.extlib.component.picker.data.IValuePickerData (implement not extend). I also needed to implement Serializable, just like we do with a bean. IValuePickerData is an Extension Library class, so the source code is freely available on the OpenNTF project and you can look at it in Eclipse. When you import the Extension Library source code into Eclipse there are quite a few Eclipse plug-in projects involved, so the plug-in project you want to look at is com.ibm.xsp.extlib.controls. Expand the src folder and look in the package com.ibm.xsp.extlib.component.picker.data.

First off, you’ll see IPickerData is not a Java class but a Java interface. If you’re relatively new to Java, you may not know the difference. An interface defines a set of properties and methods that any Java class based on this interface must implement. It specifies the property data types and method names, parameters and return types. But there is no code in the methods in the interface. It’s effectively a schema that says “You must include these methods and I don’t care your code actually does, as long as it takes these parameters and returns this type of object”. The Extension Library does provide example implementations of the IValuePickerData interface, including both the SimpleValuePickerData and the BeanValuePickerData. And there is also the example in the Extension Library Demo database.

There are four methods that have to be implemented:

getSourceLabels() takes no parameters and returns a String array. This is used by the Name Picker to define labels for each dataProvider, because the NamePickerAggregatorData allows you to add multiple dataProviders, for which you need to give a label so the user knows which is which. The Value Picker only allows one dataProvider, so we can just return null, like the two examples available.

hasCapability() takes an int parameter and returns a boolean. SimpleValuePickerData returns false in all cases whereas BeanValuePickerData calls a hasCapability(int) method of the underlying bean. Looking at the interface, it appears this is used to check what functionality can be applied to the Value Picker – label, search by key, extra attributes, search list, multiple sources, multiple aggregation. The DominoViewValuePickerData class (extended eventually from AbstractDominoViewValuePickerData class) provides all except multiple aggregation. The NamePickerAggregatorData class provides only multiple sources.

readEntries() takes an IPickerOptions object and returns an IPickerResult object. This is used to retrieve the values the user can select from. This is the first method we’ll implement.

loadEntries() takes two parameters, an array of Objects and an array of Strings. It returns a List of IPickerEntry objects. This appears to be used to validate the component the Value Picker is bound to, if validation is done, or to highlight the already selected entry / entries when the Value Picker dialog is presented to the user. This is the other method we’ll implement.

In the example of the BeanValuePicker in the Extension Library demo database, the readEntries() and loadEntries() methods both explicitly go to the States properties file and load the contents. But the aim here is to make it generic, to be able to specify the contents and load them accordingly to return the right kinds of objects.

So the first step is to add a new property, then create not only the default constructor for the class, but also two more as below:

private List options_ = null;

public ListPicker() {
}

public ListPicker(List options) {
options_ = options;
}

public ListPicker(Set options) {
options_ = new ArrayList(options);
}

So we have two additional constructors. The first takes a List and the second a Set. That’s because they are different underlying Java classes, so we can’t just pass in our TreeSet to the ListPicker(List) constructor. Nor can we pass in the ArrayList to the ListPicker(Set) constructor. But the ListPicker(Set) constructor converts the Set to an ArrayList, so we have a consistent approach.

Next we’ll go on to creating the readEntries() and loadEntries() methods and bind the ListPicker to our XPage.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top