This chapter is from the book
This chapter is from the book
This chapter is from the book
Repeat Control
The Repeat control is similar to the Data Table. The Repeat control does not have a table structure, but just like the Data Table, it can contain arbitrary controls that can be bound to elements of a collection object (like a Domino view or Java array). When the Repeat control is rendered, all child controls are repeated for each entry in the data source.
In fact, to prove just how similar the two controls are, do a quick exercise that involves rebuilding the previous Data Table as a Repeat. The steps are
- In the Designer Navigator, copy and paste the dtProfile.xsp XPage.
- Rename the new copy from dtProfile_1 to repeatProfile and open it in Designer (the Designer right-mouse menu has a Rename option).
- Use the Find/Replace dialog (Ctrl-F) to replace all occurrences of dataTable with repeat.
- In the Source pane, delete all the <xp:column ...> and </xp:column> tags from repeatProfile.xsp.
- Just before the closing repeat tag, </xp:repeat>, insert a line break using these tags <xp:br></xp:br>.
- Move to the WYSIWYG editor and manually insert some spaces between the child controls so they are not touching each other.
Reload or preview the page and presto! Your new page is now working just as the Data Table page did, although the individual elements do not align as neatly as they would when placed in a table. If you executed the six steps correctly, your repeatProfile.xsp should contain the same markup as Listing 9.9.
Listing 9.9. Displaying Profile Data Using a Repeat Control
<!-- data source has not changed. -->
<xp:this.data>
<xp:dominoView var="view1" viewName="xpAuthorProfiles">
</xp:dominoView>
</xp:this.data>
<!-- dataTable tag changed to repeat -->
<xp:repeat id="repeat1" rows="30"
var="rowData" style="width:400px" value="#{view1}"> 
<!-- removed columns but kept controls exactly as they were -->
<xp:text escape="true" id="computedField1">
<xp:this.value><![CDATA[#{javascript:
@Name("[CN]", rowData.getColumnValue("From"));}]]>
</xp:this.value>
</xp:text>
<!-- spaces represented as HTML entities in markup:   -->
  
<xp:link escape="true" text="e-mail ..." id="link1">
<xp:this.value><![CDATA[#{javascript:"mailto:" +
rowData.getColumnValue("Email");}]]></xp:this.value>
</xp:link>
  
<xp:link escape="true" text="download ..." id="link2">
<xp:this.value>
<![CDATA[#{javascript:"/" +
rowData.getUniversalID() + "/$FILE/" +
rowData.getColumnValue("FileUpFilename")}]]>
</xp:this.value>
</xp:link>
  
<xp:image id="image1" style="height:50px;width:50.0px">
<xp:this.url>
<![CDATA[#{javascript:"/" +
rowData.getUniversalID() + "/$FILE/" +
rowData.getColumnValue("FileUpFilename")}]]>
</xp:this.url>
</xp:image>
<xp:br></xp:br>
</xp:repeat>
This exercise shows that the bulk of the properties are shared across both controls and that the containment relationships are compatible—otherwise, your page would not build in Designer, let alone actually work at runtime.
A Repeat Control Design Pattern
Just because the Repeat control is not contained within a table does not mean it cannot use a tabular layout scheme. The All Documents page in the Discussion template provides a great pattern for Repeat usage. If you go back to Figure 9.1, which illustrates all the fancy features of the Repeat control, you see the page does have a tabular structure. The top of the view has a set of Collapse All | Expand All links and a pager—effectively, this is a header. The bottom of the view has a page size picker on the left side and a pager on the other—effectively, this is a footer. The data rows are repeated in between the header and footer using a Repeat control and make use of many other advanced features to generate dynamic content. Figure 9.29 features an outline view of the relevant parts of the page, tagged with pointers identifying various recognizable landmarks.
){kind=link}
)
Figure 9.29 Outline structure of the all documents view
As you can see, the header and footer are encapsulated as HTML tables. This content is static, so an HTML table works fine for containment and layout. The middle section, which comprises all the data rows, is also contained in a HTML table, although this may not be immediately obvious. Note that the Repeat has a header facet, which emits an HTML <table ...> tag, and a footer facet, which closes the table tag with </table>. Again, header and footer facets are not repeated but just rendered once, so this sets up a middle table for the data rows. A table row is then repeated for each entry in the data source (xpAllDocuments) and the various table cells are populated with controls, and then bound, formatted, and scripted as required. The only element to be iterated over and repeated, therefore, is the HTML table row tags (<tr>), which makes the entire process efficient but, at the same time, well structured. This Table | Repeat | Table pattern is a recommended as a best practice for complex views of this nature.
Nested Repeats
Some of the tricks used in the data rows are definitely worth exploring. For example, when it was stated earlier that the Repeat control can contain arbitrary child controls, this does not exclude other Repeat control instances. There is a good example in the allDocumentsView custom control of a nested Repeat being put to smart use. The particular snippet of XSP markup is displayed in Listing 9.10, with some comments added in bold script.
Listing 9.10. Nested Repeat Control Bound to a JavaScript Array
<!-- Nested Repeat control – note removeRepeat="true" -->
<xp:repeat id="repeatTags" rows="30" var="tagData"
first="0" indexVar="tagIndex" repeatControls="false"
removeRepeat="true"
themeId="Repeat.Tags">
<!-- Repeat is not bound to a View but to a Java array! -->
<xp:this.value><![CDATA[#{javascript:
// Category can be a single string or multi-text item
var obj = rowData.getColumnValue("_Categories");
var size = 0;
var array = null;
// must return an array regardless!
if(typeof obj == "string"){
var str = obj.toString();
if(str != null){
array = new Array();
array[0] = str;
size = 1;
}
}else if(typeof obj == "java.util.Vector"){
array = obj.toArray();
size = array.length;
}
return array;}]]>
</xp:this.value>
<!-- create a link for each item in the tagData array! -->
<xp:link escape="true" id="link2" themeId="Link.person"
text="#{javascript:tagData}" value="/byTag.xsp">
<!-- set the ?categoryFilter param to the array item -->
<xp:this.parameters>
<xp:parameter value="#{javascript:tagData;}"
name="categoryFilter">
</xp:parameter>
</xp:this.parameters>
</xp:link>
<!-- only include a comma if multiple array items exist -->
<xp:label value="," id="label5"
themeId="Text.commaSeparator">
<xp:this.rendered><![CDATA[#{javascript:
size > 1 && tagIndex < size - 1}]]>
</xp:this.rendered>
</xp:label>
</xp:repeat>
This nested Repeat control is created on the fly, along with some other sibling controls, whenever the end-user expands a top level row using the More link. The Repeat control's value property does not in fact point to a view data source, as has been the norm up to now, but to a Java array that contains one or more tags, i.e. tags are the contents of the _Categories multivalue field. Within this nested Repeat, a Link control is created for each category found in the tag array. The link text is set to the tag text and the link value (URL) is set to the byTag.xsp XPage plus a categoryFilter parameter, which is also set to the tag text (for example, /byTag.xsp?categoryFilter=Government). After all the links are generated, the Repeat removes itself from the component tree (removeRepeat="true"), because it is no longer required. Play with the sample application and see this feature in action. You can probably think of use cases for your own applications that would be well served using dynamic nested Repeats in this way.
The Rich Get Richer
One little amendment you could make to further enhance the rich nature of the Repeat control content is to insert the actual rich text into the dynamic row when the More link is clicked. Right now, it is the plain text stored in the Abstract column of the xpAllDocuments view that is displayed, but if you locate that value binding in the custom control (search all DocumentsView.xsp for "cfAbstract" ), you could replace it, as shown in Listing 9.11.
Listing 9.11. Server-Side JavaScript Code to Extract HTML from Rich Text Fields Saved in MIME Format
// search for "Abstract" and comment out this next line of code
// return rowData.getColumnValue("Abstract");
// get the Notes document and body rich text field
var nd:NotesDocument = rowData.getDocument();
var mime = nd.getMIMEEntity("body");
// if it is MIME then you can passthrough as HTML
if (mime != null) {
return mime.getContentAsText();
}
// Otherwise just return the plain text
else {
return nd.getItemValueString("body");
}
You need to configure the cfAbstract Computed Field to have a content type of HTML. This has been done for you in the allDocumentsView custom control, but the code is commented out. If you would like to see this feature in action, simply enable the code in Designer. Figure 9.30 shows some sample rich content expanded in the Repeated rows.
)
Figure 9.30 Expanded Rich Text Content in Repeat Control
Obviously, it is not efficient to open documents when building views, although this only occurs when the user clicks the More link, so the expense is only incurred on request and not for every repeated item. This example concludes our discussion of the Repeat Control.