A 4 minutes read, written by Kevin
July 29, 2014
Many of our clients such as Fiserv, the City of Surrey, and the City of Edmonton, among others, use OpenText WSM as their content management system solution. Part of my job is to come up with novel ways to allow our clients to use the environment in a way that suits them best.
Recently, I worked on multiple projects where clients asked us to develop a method to present lists of content on pages in a way that proved challenging using the standard methods provided by OpenText. With the help of a fellow developer, we came up with a solution that provided the client the needed functionality in a way that appears built-in to the environment.
To loop over a list and pull in information from a child page, all that is necessary is to use a list block mark to get the information that is required from the child page.
For example, to loop over a list named lst_navigation that has been set to transfer the element content of following pages, consider the following code typically found in a template:
<!IoRangeList> <!IoRangeNoRedDotMode><!IoRangeRedDotMode><%lst_navigation%><!/IoRangeRedDotMode><!/IoRangeNoRedDotMode> <%hdl_title%> <%txt_description%> <!/IoRangeList>
Assuming that the child pages have the indicated placeholders defined, the above code will output the heading and description for each child page connected to
At times, there may be a requirement to loop over a list on a child page to pull in information from lower-level child pages that are connected to that list. Unfortunately, the
<!IoRangeList>tag cannot be nested, so the above method will not work to loop over a list contained on a child page. A different method of obtaining this data is required, so we turn to RenderTags to obtain the data needed.
One common way of obtaining this data is to loop over the list on the main parent page using a
<!IoRangeList>tag to get the first-level child page data and then use RenderTags to loop over a list on those pages in order to get lower-level child page information to get around the constraint of not being able to use nested
<!IoRangeList>tags. At first thought, it might make sense to use something like the following code block to achieve this:
<!IoRangeList> <!IoRangeNoRedDotMode><!IoRangeRedDotMode><%lst_navigation%><!/IoRangeRedDotMode><!/IoRangeNoRedDotMode> <!—Information from child pages of the child page. --> <%!! Store:childItem.Headline !!%> <%!! Store:childItem.Elements.GetElement(txt_description).Value.ToString() !!%> <!/IoRangeList>
The above code will loop over the child pages connected to the
<%lst_navigation>placeholder of the main page. It will then use the page GUID transferred from each child page to find and target the
<%lst_navigation%> placeholder of each child page and loop over that list. The headline and description of the targeted second-level child pages are then displayed.
While the above code block correctly returns the desired information, the order in which the pages are returned is determined by the CMS and isn’t easily controlled. Any set page or navigation ordering is ignored. To make sure the ordering of the returned items can be controlled, a different solution would be needed, such as using the available page indexes and loop over those to get the desired information.
Using page indexes will also return the expected data, but furthermore will allow the page order to be set using the navigation order setting for the list. This will enable the user to determine the order in which the information is to be displayed. Note: This approach will require that the pages are accessible in navigation so that they can be found in the navigation indexes.
The above code block can now be modified to use the index of each page as it appears in navigation:
<!IoRangeList> <!IoRangeNoRedDotMode><!IoRangeRedDotMode><%lst_navigation%><!/IoRangeRedDotMode><!/IoRangeNoRedDotMode> <!—Information from child pages of the child page. --> <%!! Store:childItem.Page.Headline !!%> <%!! Store:childItem.Page.Elements.GetElement(txt_description).Value.ToString() !!%> <!/IoRangeList>
The foreach loop will now follow the navigation order that has been set for the lists on each first-level child page.
In SmartEdit, the command for opening the “Edit Navigation Order” dialog box can be found for a page by opening the page for editing, right-clicking on the page, and selecting “Edit Navigation Order”. In order to edit the navigation order for child pages from a parent page (as opposed to opening the child page for editing and setting the list’s navigation order from that page), a red dot can be provided for the user in SmartEdit mode with the following code that can be placed just before the opening
</code> tag above:</p>
If converting existing pages to use this format, be sure that the child pages are master pages and are part of the defined navigation tree. As well, check the current navigation order of the lower-level child pages to make sure that they have been added to the navigation tree. If there are pages connected yet none visible in the navigation sort order dialog box, then the pages may need to be removed from the list and reconnected so that they are properly added (see this blog post for more details on how to do this). This solution was found to work in OpenText Management Server 10.1 and may not work in newer versions of the product, so please test thoroughly if using this code in your templates.
Source: Looping over child page lists in OpenText WSM using Indexes
© copyright 2014 by yellowpencil