Control rendering of content on a SkyVault Share page

If you are logged in as admin these will be component-1-1, user/admin/dashboard and page respectively.

<module>
  <id>Module (Hide My Sites)</id>
    <components>
       <component>
          <region-id>component-1-1</region-id>
          <source-id>user/{userid}/dashboard</source-id>
          <scope>page</scope>
          <sub-components>
             <sub-component id="default">
                <evaluations>
                  <evaluation id="guaranteedToHide">
                      <render>false</render>
                  </evaluation>
                </evaluations>
              </sub-component>
          </sub-components>
        </component>
     </components>
</module>

Note that the source-id element uses a parameterized value. This will be discussed in more detail later in this tutorial.

Some features introduced in this tutorial are explained in more detail in the following sections:

Parameterized source-id mapping: Every SkyVault Share user gets their own dashboard page, which enables them to customize the layout to suit their own needs, but each user dashboard is generated from a single preset. In this tutorial you specify user/{userid}/dashboard. Note the use of the user variable. This allows you to change the appearance of the dashboard for any user, not just the admin user.

Extending existing Sub-Components: When the dashboard pages were first created, the concept of Sub-Components in Spring Surf did not exist. Consequently, if you search through the existing dashboard configuration files you will not find Sub-Components specified. Spring Surf automatically converts these "legacy" Components into the new extensible Components containing a single Sub-Component with the ID "default". These new extensible Components are called Advanced Components.

This allows you to add new content to these legacy Components through Sub-Components, or customize the original content without affecting any new content. In the previous configuration XML, you can change the behaviour of the components through modification of the default Sub-Component.

Note that multiple modules can extend the same Component, which is why the deployment order of modules is important.

Sub-Component evaluations: Every Sub-Component can optionally have zero or more evaluations. Each evaluation acts like an AND gate to a series of evaluators where an evaluation is considered successful if no evaluators fail. If an evaluation contains no evaluators, it is still considered to have evaluated successfully because nothing has failed.

The purpose of an evaluation is to change the behavior of a Sub-Component in one of three ways:

In this example, you are simply overriding the default behavior of the Sub-Component to prevent it from rendering by setting the <render> element to have a value of false (this defaults to true) if not defined.

Module deployment: It would have been possible to add the <sub-component> elements (and its children) into the module created in the previous tutorial, as a single module can update multiple Components and Sub-Components.  Adding the configuration to prevent rendering of the My Sites component as a separate module allows you to deploy and undeploy both extension modules independently. If you deploy both modules, you will see that both modules are active.