IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

The low-down:

XPages lets you write code to calculate the values for selection lists. The value your code returns may either be an array of strings, using the pipe symbol ("|") as a delimiter between display value and stored value, or it may be an array of javax.faces.model.SelectItem objects, which each contain a display and stored value as separate data items. It's your choice. The latter method, however, is more bulletproof since you don't have to worry about pipe symbols in your data.

Experienced Domino developers are used to specifying the choices for keyword lists -- comboboxes, radio buttons and the like -- using the pipe symbol ("|") as a delimiter between the value displayed and the value stored, hence: "Yes|1", "No|0".

For XPages, the Designer UI provides a separate place for entering the display value and stored value if you have a hard-coded list:

Image:XPages best practice: computed selection lists
If you need to calculate the value of the selection list at runtime, using the pipe delimiter is still an option. Here, for instance, is the XSP code for two hardcoded choices and two calculated choices (or whatever number the code chooses to return). For simplicity, the calculation produces a constant value, but use your imagination.

<xp:radioGroup id="radioGroup1" defaultValue="0">
       
<xp:selectItem itemLabel="Yes" itemValue="1"></xp:selectItem>
       
<xp:selectItem itemLabel="No" itemValue="0"></xp:selectItem>
       
<xp:selectItems>
               
<xp:this.value>#{javascript:(["Maybe|2" , "None of your business|3"])}]]></xp:this.value>
       
</xp:selectItems>
</
xp:radioGroup>

This works. Or, you can return an array of objects:

<xp:selectItems>

        <xp:this.value>#{javascript:([new javax.faces.model.SelectItem("2", "Maybe"), new javax.faces.model.SelectItem("3", "None of your business")])}]]></xp:this.value>
</
xp:selectItems>


Although it's somewhat longer, the nice thing about the latter example is that it doesn't fail if the "display value" contains a pipe symbol. This can occur in any case where you don't control the incoming data (for instance, if the choices are looked up from data in user-created documents). Or, as in my previous blog entry, the pipe symbol is used if you're using an application with localized values in it. When the .properties files are automatically generated, the to-be-translated strings in the foreign-language .properties files are prefixed with a string which includes a pipe symbol:

radioGroup1/xp\:selectItem[1]/@itemLabel=[sq| Yes ]
radioGroup1/xp\:selectItem[2]/@itemLabel=[sq| No ]

So if your strings are somehow derived from .properties files, the application will fail to work in other than the original language until translation is complete. That is, of course, only one way that "|" can get into your data, so if you want to be safe, use the SelectItem object -- even if you have no intention of translating the application.

Andre Guirard | 24 May 2013 09:46:05 AM ET | | Comments (1)


 Comments

No Comments Found

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact