XPages: Validation for Radio Buttons, Check Boxes and List Boxes: Part Five

Home » XPages: Validation for Radio Buttons, Check Boxes and List Boxes: Part Five

Option Three is a modification of Option Two, which reproduced the client-side validation available for other XPages controls, with a javascript alert. At this point I should add some background to the application I was working on. The application in question is a major upgrade of our enterprise feedback tool, EFT, which added in Dojo styling, used NotesView2. I had already developed much of the application using classic notes web development and dojo before I attended an XPages course, but I took the opportunity to remove the agent that generated HTML on the fly for the survey response form, and replace it with XPages. But I still wanted to reproduce the dojo validation styling available across the rest of the application. The sample database (fully updated now) has a slightly simplified structure to my application but with the removal of some of the extended functionality you see in the demo I provided (e.g. Page separators, comments boxes for questions, multiple comments boxes for checkboxes) and some functionality not seem in the demo (e.g. demographics questions, confidence ratings for questions). The limitation here is that option 3 does not work in 8.5.1.

You can see, edit and add the relevant answer documents via the Notes Client in the Answer Docs 8.5 view. In the design you will find the XPage design element option3.xsp. beforeRenderResponse code on the XPage forces compatibility mode for Internet Explorer, and a number of resources are defined. Of these, note domino.form.FilteringSelect, a modified dojo javascript file created by Viktor Krantz that will need to be saved to your server (directions on where to save it are in my sample database’s About document). This handles makes it easier to pass options to a filteringSelect than using the basic dojo widget. The XPage also references option3Validation.js, the client-side javascript that runs everything. Within the Xpage is a repeat control, passing the UNID for each row entry to a custom control called AnswerDoc. For ease of readability, I then have separate custom controls for the various answer types rendered or not according to the answer type.

It would be feasible for the repeat control to pass a DominoDocument data element, as John Mackey details. But the crucial setting is repeatControls property set to true. Although I can’t find full documentation about what this does, it looks like it changes the order of when the server gets the data to show within the repeat, allowing it to be available for the XPage events and other custom controls. However, it also caused my paging function, which changed a viewScope variable for the starting question and reloaded the page, to stop working, which is why I am passing the unid.

The convertTextBox, convertValidationTextBox and convertDropDown custom controls all use an inputText field to store the value. A script block then converts the field to the relevant dojo type, defining a value, prompt message, required property, invalid message and attaching a validator, if the question has been marked as mandatory. Much of this could be done setting properties directly on the input controls, including the filteringSelect, but this method will show what can be done with XSP.addOnLoad and is analagous to the code for the other custom controls.

The convertRadioButton_8_5 custom control uses the following code:

<xp:radioGroupid=

“response”

 

value=“#{ansDoc.response}”layout=“pageDirection”><xp:selectItems><xp:this.value>#{javascript:if (@Contains(ansDoc.getItemValue(“aChoices”), “|”)) {

ansDoc.getItemValue(“aChoices”);

} else {

ansDoc.getItemValue(“aChoices”) + “|” + ansDoc.getItemValue(“aChoices”);

}}

]]>xp:this.value

 

>

 

 

 

 

 

>

 

 

 

 

 

 

>

 

 

 

 

<xp:scriptBlockid=“scriptBlock1”

 

>

 

<xp:this.value

>

var convertInput = function() {

var userPrompt = “#{ansDoc.PromptMessage}”;

 

if (userPrompt != “”) {

 

new dijit.Tooltip({connectId: [“#{id:response}”], label: userPrompt});

 

}

 

if (“#{ansDoc.Mandatory}” == “Y”) {

 

XSP.attachValidator(“#{id:response}”, new XSP.RequiredCheckValidator(“#{ansDoc.mandError}”));

 

}

 

};

 

XSP.addOnLoad(convertInput);

 

 

]]>xp:this.value

 

>

 

 

xp:scriptBlock>

We use a Radio Group control that holds the options. As with the other custom controls we have a script block that adds the prompt message tooltip and the RequiredCheckValidator validator – the same function used in Option 2. convertCheckBox_8_5 is the same, except using the CheckBox Group. convertMultiSelect_8_5 needs a different type of validator, RequiredListBoxValidator.

 

 

 

 

 

 

 

Looking now at option3Validation, I’ve included the RequiredValidator function just for comparison. RequiredCheckValidator is the same as Option 2. RequiredListBoxValidator is similar to RequiredCheckValidator in using a dojo query, but this time using the select option, because with the RequiredValidator attached it always fails validation. The difference is now in XSP.validationError:

XSP.validationError =

 

function validationError(clientId,message)

 

{

 

 

 

 

 

 

//Overrides validationError for this application.

//Doesn’t select field,shows error, sets to error

 

 

 

 

 

var e = this

.getElementById(clientId);

 

if(e!=null)

 

{

 

 

 

 

 

 

//e.focus();

 

 

 

 

if (dijit.byId(clientId) == null)

 

{

 

 

 

dijit.showTooltip(message, dojo.byId(clientId));

dojo.byId(clientId).style.backgroundColor =

 

“rgb(255,247,189)”

;

 

} else {

 

 

dijit.showTooltip(message, dijit.byId(clientId).domNode);

dijit.byId(clientId).state =

 

“Error”

;

dijit.byId(clientId)._setStateClass();

 

 

}

}

 

}

 

 

The highlighted section checks if we have a dijit widget with the ID passed in. You may remember from Part Two that with Radio Group and CheckBox Group controls, the ID is not assigned to athe radio button but to a table that contains the radio buttons. So we add a tooltip to and style the table, the dojo element with the id matching the parameter clientId. For the other design elements, we show a tooltip on the dijit widget’s parent node and, because they are widgets, we can utilise dojo’s in-built functions to set the dijit widget’s state to “Error” and style accordingly.

Validated Form

The result is validation of each field in turn, highlighting uncompleted mandatory questions with a yellow background and tooltip advising the user of our error message. However, this only works on 8.5. In the final part I will cover the final solution that validates all fields at once and works on 8.5 and 8.5.1.

 

1 thought on “XPages: Validation for Radio Buttons, Check Boxes and List Boxes: Part Five”

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