Pages, and shared, derived, and hidden pages
Understand the behavior and difference between shared pages derived pages, and hidden helps you manage pages and create the right type of page for needs.
A page is an organization element that defines how content is displayed. A page can contain portlets and other pages. Shared pages enable you to share a layout model with multiple pages. After a page is shared, other pages can reference the layout of the shared page. Derived pages are children of shared pages and have specific behavior you should be aware of.
Derived pages inherit the properties of the original page. Creating a derived page is equivalent to creating a new, specialized layer on the original page. The original page and the new layer are aggregated together at rendering time. The new layer is contained within and controlled by the original page. Referencing an existing page allows you to give administrative access to other users while maintaining the content and layout from the original page. The following implications apply to derived pages:
Changes made to the original parent page may be reflected to the derived pages that reference it. Layers can be created on other layers to create a chain of cascading pages, referred to as delegated page specialization. This process means that a root page can be created, and the top level administrator can decide the initial layout and content of the page. The next level administrator can then control and modify a specialized layer of this page, adding more content and layout. This process can continue down a chain of page managers and submanagers. Managers or submanagers in the chain only see their individual layer of the chain; however, they must have the User role for every layer above theirs in order to see the content of the previous layers. A user is only able to see a layer of the page if appropriate access is given. Here are some examples to illustrate this concept.
- If content is locked on the page that is referenced, content is locked on all derived pages that reference that page.
- If a portlet is deleted from the page that is referenced, the portlet is deleted from all pages that reference that page, and all individual user settings for that portlet are lost.
- The user must have access to the original page to access the derived page. Therefore private pages cannot be shared in this manner.
John, the superadministrator, creates a page named Home and titles it Home. Brandy, a subadministrator, manages the next level of this page, named Home_operations, and determines what additional content should be added to the Home page for employees in the operations group. Nick, the next level administrator, manages the next level of the Home page, Home_operations_transportation, and determines the content that should be available on the Home page for employees in the transportation department. Nick, as the transportation page administrator, must have the Manager role for Home_operations_transportation so that he can make changes to this page that will affect all users, as well as the User role for Home_operations and the User role for Home; he must have the User role on every layer that combines to create the Home_operations_transportation level. Desi, a user of the Home_operations_transportation page, must have the User role for Home_operations_transportation, and she must also have the User role for Home_operations and the User role for Home. When Desi, the user logs on to the portal, she sees one Home page. This Home page will be an aggregation of all the layers associated with the root Home page.
Notes:
- If you delete a page that is referenced by another page, all pages that reference that page are deleted.
- The markup specified for the root page cannot be modified on derived pages. The whole derivation tree structure with all layers supports the markup that is specified on the root page.
- The ability to change the title and description of derived pages can be disabled in the portal configuration. Refer to the description for the allow.derived.titles parameter in Portal configuration services for details.
Parent
Work with pages
Portal configuration services
Hidden pages
Some scenarios and use cases require pages that do not show in the portal, but contain portlets that can be launched from other pages. Such hidden pages do not appear in the site navigation, but are launched from generated links in portlets or theme code. For ease of administration and conserving system resources, you can place and manage such pages in one place. An example is the People Finder: users can launch it from a link in the theme, but the portlet instance itself is located on a hidden page in the content model.The easiest way to create a hidden page for such purposes is to create the page under the Hidden Pages label, which is a child of the content root. This label is hidden from the navigation. It is a container for hidden pages in the portal, and it minimizes the cycles required to render the top navigation links while still providing support for hidden pages.
If you use legacy themes, be aware that they render the top navigation based on the level specified in theme policy or page metadata to render the navigation at the appropriate level. If you use such a theme and you create a new hidden page under the Hidden Pages label, set the metadata value com.ibm.portal.themepolicy.topNavigationStartLevel for the page to 3.