Configuring the UI

Now that the model is defined, you could begin using it right away by writing code against one of Alfresco's APIs that creates instances of your custom types, adds aspects, and so on. In practice, it is usually a good idea to do just that to make sure the model behaves as you expect. But you'd probably like to log in to the web client to see the fruits of your labor from the last section, so let's discuss what it takes to make that happen. By the end of this discussion, you will be able to use the web client to work with the SomeCo-specific content model to do things such as these:

  • Display and update custom properties and associations
  • Create instances of SomeCo-specific content types
  • Configure actions that involve SomeCo types and aspects
  • Use Advanced Search to query with SomeCo-specific parameters

Configuring the UI to expose the custom content model involves overriding and extending Alfresco's out of the box web client configuration. To do this, you'll create your own SomeCo-specific version of the web client configuration XML that overrides Alfresco's. For more details on how the out of the box web client configuration is structured and what is available to be extended, refer to the Appendix.

Step-by-Step: Adding Properties to the Property Sheet

When a user looks at a property sheet for a piece of content stored as one of the custom types or with one of the custom aspects attached, the property sheet should show the custom properties. If there are associations, those should be shown as well:

Step-by-Step: Adding Properties to the Property Sheet

In order to configure the properties sheet to show custom properties and associations, follow these steps:

  1. In the client-extensions Eclipse project, create a new XML file called web-client-config-custom.xml in the extension directory if it isn't there already. If you are creating it from scratch, populate it with an empty alfresco-config element. You'll add child elements to it in the subsequent steps.
  2. To add properties to property sheets, use the aspect-name evaluator for aspects and the node-type evaluator for content types. SomeCo has two aspects that need to be added to the properties sheet: sc:webable and sc:clientRelated. For sc:webable, add the following config element to web-client-config-custom.xml as a child of alfresco-config:
        <!--  add webable aspect properties to property sheet -->
         <config evaluator="aspect-name" condition="sc:webable">
          <property-sheet>
           <show-property name="sc:published" display-label-id="published" />
           <show-property name="sc:isActive" display-label-id="isActive" read-only="true" />
          </property-sheet>
         </config>
  3. Add the config element to show the properties for the clientRelated aspect on your own.
  4. Add the following to display the relatedDocuments association for SomeCo documents and Whitepapers:
         <config evaluator="node-type" condition="sc:doc">
          <property-sheet>
           <show-association name="sc:relatedDocuments" />
          </property-sheet>
         </config>
    
         <config evaluator="node-type" condition="sc:whitepaper">
          <property-sheet>
           <show-association name="sc:relatedDocuments" />
          </property-sheet>
         </config>
  5. Add the following to display the campaign property for SomeCo Marketing Documents:
        <!-- show campaign on maraketingDoc property sheet -->
        <config evaluator="node-type" condition="sc:marketingDoc">
         <property-sheet>
          <show-property name="sc:campaign" display-label-id="campaign" />
         </property-sheet>
        </config
  6. Save the file.
  7. Deploy the customizations (ant deploy), restart Tomcat, and test.

In Chapter 2, you deployed a small set of customizations to validate your development environment. With the web client configuration modifications you just made, you should be able to log in to Alfresco and create instances of Marketing and Whitepaper documents. When you look at the properties for an instance of a Whitepaper, you should see a component that lets you pick Related Documents:

Step-by-Step: Adding Properties to the Property Sheet

When you look at the properties for an instance of a marketing document, you should see a component that lets you choose the associated campaign:

Step-by-Step: Adding Properties to the Property Sheet

Note that you may see some placeholder text for the Campaign label (and corresponding warnings in the log) because you haven't externalized that label yet. We'll fix that shortly.

Externalizing Display Labels

Note the display-label-id attribute of the show-property element in the previous code. An alternative is to specify the label explicitly in this file using the label attribute. But a better practice is to externalize the string so that the interface can be localized if needed, so this example uses display-label-id. The actual label value is defined elsewhere in a resource bundle.

Making Properties Read-Only

In the previous code, the read-only attribute on the show-property element for sc:isActive prevents web client users from editing the property. It does not, however, prevent the property from being set through scripts or API calls. In this case, SomeCo wants it to be "read-only", so that it can be set through other means such as by actions or during an approval step in a workflow.

Step-by-Step: Adding Types and Aspects to WebClient Dropdowns

When a user clicks Create or Add Content, the custom types should be a choice in the list of content types. And when a user configures a rule on a space and uses content types or aspects as a criterion or action parameter, the custom types and aspects should be included in the dropdowns.

When you tested your last change you probably noticed that the types you created in Chapter 2 were shown, but not the types you added in this chapter for Legal, HR, Sales, and so on. Similarly, if you tried to add the client-related or webable aspects to an object, you weren't able to select either aspect from the list.

Just as you did for custom properties and associations in the previous example, you have to override Alfresco's web client configuration to get custom types and aspects to show up in the web client.

To add custom types and aspects to the appropriate dropdowns, follow these steps:

  1. Edit web-client-config-custom.xml.
  2. To add content types to the list of available types in the create content and add content dialogs, use the string-compare evaluator and the Content Wizards condition. Add the following to web-client-config-custom.xml beneath the previous config element:
         <!--  add someco types to add content list -->
         config evaluator="string-compare" condition="Content Wizards">
          <content-types>
           <type name="sc:doc" />
           <type name="sc:whitepaper" />
           <type name="sc:legalDoc" />
           <type name="sc:marketingDoc" />++
           <type name="sc:hrDoc" />
           <type name="sc:salesDoc" />
           <type name="sc:opsDoc" />
          </content-types>
            </config>
  3. The list of types and aspects used when rule actions are configured are all part of the same config element. The Action Wizards config has several child elements that can be used. The aspects element defines the list of aspects shown when the add aspect action is configured. The subtypes element lists types that show up in the dropdown when configuring the content type criteria for a rule. The specialise-types element (note the UK spelling) lists the types available to the specialize type action. Add the following to web-client-config-custom.xml below the previously added config element:
        
    <config evaluator="string-compare" condition="Action Wizards">
         <!-- The list of aspects to show in the add/remove features action -->
             <!-- and the has-aspect condition --> 
          <aspects>
           <aspect name="sc:webable"/>
           <aspect name="sc:clientRelated"/>
          </aspects>
    
          <!-- The list of types shown in the is-subtype condition -->
          <subtypes>
           <type name="sc:doc" />
           <type name="sc:whitepaper" />
           <type name="sc:legalDoc" />
           <type name="sc:marketingDoc" />
           <type name="sc:hrDoc" />
           <type name="sc:salesDoc" />
           <type name="sc:opsDoc" />
          </subtypes>  
    
           <!-- The list of content and/or folder types shown in the specialise-type action -->
          <specialise-types>
           <type name="sc:doc" />
           <type name="sc:whitepaper" />
           <type name="sc:legalDoc" />
           <type name="sc:marketingDoc" />
           <type name="sc:hrDoc" />
           <type name="sc:salesDoc" />
           <type name="sc:opsDoc" />
          </specialise-types>  
         </config>
  4. Save the web-client-config-custom.xml file.
  5. Deploy your changes using ant deploy, restart Tomcat, and test.

To test these changes out, log in to the web client. Now when you create new content, all of the SomeCo types should be in the content type dropdown:

Step-by-Step: Adding Types and Aspects to WebClient Dropdowns

To test the aspect-related changes, configure a new rule on a space. The first step when defining a rule action is to identify the criteria for running the action. If you select either Items that have a specific aspect applied or Items of a specified type or its sub-types, you should see the SomeCo custom types when you click Set Values and Add:

Step-by-Step: Adding Types and Aspects to WebClient Dropdowns
Step-by-Step: Adding Types and Aspects to WebClient Dropdowns

The SomeCo custom types should also be listed as content type choices for the specialize type action, and custom aspects should be listed as choices for the add aspect action. To test this, view the details for a folder or a piece of content and then click Run Action to launch the rule action wizard. When choosing either the specialize type or add aspect actions, the list that gets displayed when you click Set Values and Add should include items from the custom model.

Step-by-Step: Adding Properties and Types to Advanced Search

When a user runs an advanced search, he or she should be able to restrict search results to instances of custom types and/or content with specific values for the properties of custom types. As before, this involves modifying web-client-config-custom.xml.

To add custom properties and types to the advanced search dialog, follow these steps:

  1. The Advanced Search config specifies which content types and properties can be used to refine an advanced search result set. Add the following to web-client-config-custom.xml below the previously-added config element.
        <config evaluator="string-compare" condition="Advanced Search">
         <advanced-search>
          <content-types>
           <type name="sc:doc" />
           <type name="sc:whitepaper" />
           <type name="sc:legalDoc" />
           <type name="sc:marketingDoc" />
           <type name="sc:hrDoc" />
           <type name="sc:salesDoc" />
           <type name="sc:opsDoc" />
          </content-types>
          <custom-properties>
           <meta-data aspect="sc:webable" property="sc:published" display-label-id="published" />
           <meta-data aspect="sc:webable" property="sc:isActive" display-label-id="isActive" />
           <meta-data aspect="sc:clientRelated" property="sc:clientName" display-label-id="client" />
           <meta-data aspect="sc:clientRelated" property="sc:projectName" display-label-id="project" />       
          </custom-properties>
         </advanced-search>
        </config>
  2. Deploy the changes by running ant deploy, restart Tomcat, and test.
  3. To test out this change, log in to the web client and go to Advanced Search. The SomeCo types should be listed in the Content Type dropdown. The custom properties should be listed under Additional Options:
Step-by-Step:UI, configuringcustom types, adding to webclient UI, configuringaspects, adding to webclient Adding Properties and Types to Advanced Search

Step-by-Step: Setting Externalized Label Values

You probably noticed when you were testing the web client changes that all of the labels were showing unresolved label IDs. You need to create a new properties file to fix that. The file will hold name-value pairs that match the display-label-id attributes in web-client-config-custom.xml.

To configure the label IDs, follow these steps:

  1. Create a file called webclient.properties in the same directory as web-client-config-custom.xml.
  2. In this example, there are five properties that need labels. Populate webclient.properties as follows.
       #sc:webable
       published=Published
       isActive=Active?
    
       #sc:clientRelated
       client=Client
       project=Project
    
       #sc:marketingDoc
       campaign=Campaign
  3. Deploy your changes by running ant deploy, restart Tomcat, and test.
  4. Log in to the web client and open the properties for a document. Now the label IDs should be resolving to the externalized string values.
Step-by-Step: Setting Externalized Label Values

Note

At the time of this writing, there was a bug related to web client configuration property files and AMPs (AWC-1149). If you want to deploy the project as an AMP, your webclient.properties file will need to go into alfresco|extension instead of your module-specific directory. Until this issue is resolved, this means there is the possibility of an overwrite if the directory already contains a webclient.properties file. For more information on deploying AMPs, see the Appendix.

Setting up Additional Locales

The whole point in externalizing the labels is that the client can be localized to multiple languages. If you want to create a set of labels for a specific locale, you would create a file in the extension directory called webclient_[locale].properties with the same keys and their localized values.