ABOUT FIELD DESCRIPTION IN THE CRM WEB UI. The Controller class of the View (the one following the ...IMPL pattern) handles various tasks, amongst which the specification of the description text for each field rendered on the View, including table header texts. In the CRM Web UI, starting from CRM 6.0 onwards, the description of a field can have multiple origins. - When the Attribute of the context node is attached to a BOL object, it is a so called Model Attribute; the defaulted description is inherited from the Data Dictionary of the corresponding structure attached to the BOL Object.
- When the Attribute of the context node is created locally, meaning in the application, it is so called a Value Attribute; the defaulted description is defined in the Wizard at the time you create this new Attribute.
These descriptions are defaulted and can be overwritten in different ways, sequenced hereafter by priority (increasing order). - The description can be overwritten in the configuration of the view. A simple yet efficient way to customize your view with the field labels of your organization.
- The description can be overwritten by a Design Layer object, a convenient method to maintain a description centrally, across various views or even applications.
- The description can be overwritten via the code logic of the view's Controller class. Though this method requires (a bit of) Abap knowledge, it allows you to play with your description dynamically.
This blog approaches the latter way of overriding the description of Attributes. CASE STUDY. In SAP implementations, my thoughts obviously firstly go for less coding as possible, though sometimes like these it can bring even more flexibility in the handling of your application. To illustrate the case, I come up with a customer requirement where a dedicated View contained a list of business transaction documents meant to be maintained altogether; a mass maintainance tool allowing the user to easily adapt the status and the partners of up to 6 partner functions. The tricky part was that the chosen 6 partner functions could be adapted via a customizing table. The column header text could not be stored statically, rather determined according to the setup of the customizing. HOW TO. - In the Component Workbench,locate your view, start the configuration and identify the fields for which you need to override the description. Here's the list of fields (table columns).
//DOCUMENTGRID/STRUCT.PARTNERPF1 //DOCUMENTGRID/STRUCT.PARTNERPF2 //DOCUMENTGRID/STRUCT.PARTNERPF3 //DOCUMENTGRID/STRUCT.PARTNERPF4 //DOCUMENTGRID/STRUCT.PARTNERPF5 //DOCUMENTGRID/STRUCT.PARTNERPF6 - Here's thecustomizing table we have defined toassign the 6 columnswith therequired Partner Functions.
- In the Component Workbench,locate the controller class of your view. Switch to change mode and create a Public Instance Method called SET_ELEMENT_TEXT.
- Code the Methodwith the code hereadter, the logic fetches the description of the Partner function and overrides the columns' header description with it.
- Redefine the Controller Method DO_VIEW_INIT_ON_ACTIVATION and Insert the call to the method SET_ELEMENT_TEXT.
RESULT. The column headers are overwritten with the description of the respective partner functions as expected. 
| 
