In this lesson, we explore the second important part of the navigator pattern - the detail page.
Learning objectives
Learn to create meaningful pages for the Contact, Company, and User cases.
In this lesson, we will focus on the structure of the detail page and not the specifics of different card patterns. For information on configuring banner, chart, and list cards as well as control details, see the relevant lessons in the Cards and the Controls sections.
Key concepts
We often use the navigator pattern to present a list of items, for example, Person, Opportunity, Service Request, and so on, which allows you to further navigate to the details for a particular item. Key workspace concepts include:
Navigator - an optional workspace portlet that displays a list of items. Clicking on an item in the list typically allows you to navigate to a detail page.
Page - arranges portlets into meaningful functional groups. You can display different pages depending on characteristics of the selected item.
Banner - an optional banner portlet to display summary information at the top of a page.
Tabs - optional grouping of portlets within a page.
The detail part of the navigator pattern is implemented as a page, or pages, with a summary banner portlet at the top with a number of tabs containing card portlets underneath. This arrangement looks something like this.
In simple cases, there is one detail page defined. For more involved cases, where the navigator list contains many different types, we define one page per subclass. For example, the Entity class hierarchy, looks like this:
Similar to what we did with dynamic columns based on type (Person, Company, and User) in the previous lesson, we will create a page per major subclass of Entity.
Entity Navigator → sysDetail event displays one of:
Contact Page
Company Page
User Page
depending on the item selected in the navigator list.
In preparation for the learning activities in this lesson, make sure that your files include the following code. If not, copy this code into your files before continuing.
idsa.training.layout.EntityDetail.caption=Entity Detail
idsa.training.layout.EntityList.caption=Entity List
idsa.training.layout.EntityList.icon=Icon
idsa.training.layout.EntityList.name=Name
idsa.training.layout.EntityList.type=Type
idsa.training.portal.Contact.caption=My Training Application
idsa.training.uievents.UIEvents.showSelection=Show Selection
idsa.training.workspace.Sandbox.caption=Sandbox
Detail page structure
Our current simple page definition in training:Sandbox.workspace has one tab containing two portlets; our entityDetail portlet and the AFL app/bus portlet. The following:
and a collection of PortletRefs that determine the portlets that show up on the tabs.
At this point, if you click on a Person, Company, or User you will get the same page. We can display different pages by type by using the page's case property, which is the name of class that this detail page is capable of displaying.
Learning activity
To add cases for Person, Company, and User:
Replace the contents of training:Sandbox.workspace with the following code:
Save, re-seed and refresh your browser. When you click on a name in the navigator, what you see depends on the type of item you've selected. The key here is the case="..." property on the pages. The page that displays is selected based on the page's case property matching the class of the selected item.
The name property of the portlet refs should be unique within the page. This is to allow automated testing tools to find the right location. A good standard is to prefix the name with some representation of the case property (here org, usr, or psn), replace : with _ in the portlet's name, and prefix with _portlet, so the mda:EntityAddresses portlet in the Organization page would have a name of org_mda_EntityAddresses_portlet.
Page selection and the case property
The first page that matches the current item's class is displayed. If no match is found, the last page in the list is used. Since the match is from top to bottom, you should place the most specific case in a class hierarchy at the top. For example, if there is a special page for UserPerson, this page should be placed above the Person page as it is more specific. Otherwise, the search matches on Person and uses that page, never reaching the UserPerson page because UserPerson is a subclass of Person.
That's about it for navigator pattern detail pages. The different types of portlets are discussed in the portlet patterns lessons.
JavaScript errors detected
Please note, these errors can depend on your browser setup.
If this problem persists, please contact our support.
XML