Ribbon Share Point 2010

With SharePoint 2010, the biggest single change from a user interface perspective is the introduction of the ribbon. With previous versions, controls and menus were spread between a few components. For example, the ListViewWebPart, which was commonly used to display list data, included its own menu system. However, when it came to managing publishing pages, a separate page editing toolbar was used. With SharePoint 2010, both of these features are delivered via the ribbon, providing a continuity of user experience between SharePoint and other Microsoft Office products.

Ribbon Architecture

To set the stage for further discussion on how the ribbon can be customized, let’s take a look at the underlying architecture and the elements that are involved. For the most part, the ribbon is defined using XML with client functionality being provided via JavaScript. Most of the functionality for the ribbon as it operates out of the boxcan be found in a number of files: the client-side script is contained in the file %SPROOT% TEMPLATELAYOUTSCUI.js, with the majority of the configuration being found in %SPROOT%TEMPLATEGLOBALXMLCMDUI.XML. An examination of the configuration file reveals the key elements that make up the ribbon:

Ribbon Architecture

Tabs

The ribbon uses tabs to show or hide groups of controls. Tabs generally refer to a particular functional area, and their visibility can be programmatically loggled so as to reduce the number of irrelevant options presented to users. Visibility can only be toggled for tabs; you can’t hide an individual control or group of controls within a tab. This is a key design element of the ribbon because it helps to reduce user confusion by ensuring that the same controls always appear in the same place.

Groups

Each tab can contain many controls. So that these controls can be further grouped into logical categories, individual controls must exist within a group.

Templates

Groups make use of templates to determine the placement of individual controls within a group. These templates can be shared between groups and assist in providing a consistent user experience.

Controls

Controls are the lowest level of user interface element that can be added to the ribbon.The types of controls are well-defined and cannot be extended; this ensures consistency of user experience. Some of the most commonly used controls include buttons, checkboxes, and drop-downs. A few task-specific controls include a color picker and an insert table control that displays a grid that can be used to specify the dimensions of a table.

Contextual Tabs

In addition to the preceding components that are the basis of the ribbon user interface, you’ll also see contextual elements such as ContextualTabs and ContextualGroup. As mentioned, tabs can be hidden when not required. However, one of the design principles behind the ribbon is that commands should be easily discoverable. As a result, tabs should not be hidden in real time. For example, if a tab contains controls for editing images, the tab should not be hidden when no images appear on the page.

Although this makes sense from a command discoverability perspective, it also means that sometimes more tabs are available than are absolutely necessary. To get around this problem, the ribbon includes the contextual group, which can contain tabs that should be visible only if a specific action is performed in the user interface. To use our image example, if the user selects an image on the page, the Image Editing Tools contextual group becomes visible, giving access to the required tabs. The difference between using tabs within a contextual group and standard tabs is that a contextual group highlights the fact that the tabs have been added and includes a group name that helps users to establish the context of the tabs.

Scaling

One other aspect of the ribbon that is also defined using XML is scaling. Another key design principle of the ribbon is the idea of spaciousness. Looking back to older products such as Excel 95, recall that the user interface consisted of many square buttons, each with a different icon. For users familiar with the product, this didn’t present an issue because they understood what the icon meant; for new users, these aspects of the user interface meant a steep learning curve. The spaciousness of the ribbon allows as much descriptive information to be added to a control as possible. Rather than using a small button with an icon, a larger button with a more illustrative icon and a text description of the command are used.

For new users, this makes life much easier.To provide user interface designers with control over how commands are represented when the ribbon is resized, each tab must define scaling rules for each group within tab. This allows user interface designers to prioritize certain commands at the expense of others if space is limited on the page. You can see this at work by navigating to a SharePoint page that contains a number of commands in the ribbon and then resizing the browser window. Generally speaking, the controls on the right side of the page will reduce in size, and the controls in the first group will retain their presentation.

Extending the Ribbon

You can add controls to the ribbon in a few ways: you can either add the controls declaratively using an elements file, or you can programmatically add controls using custom code. Let’s look at how to add a custom tab declaratively.

  1. Use the project file that we created earlier. Choose Project | Add New Item. From the Add New Item dialog, select Empty Element. Name the item MyNewTab, as shown:
  2. Extending the Ribbon

  3. Add the following code to the Elements.xml file in the MyNewTab folder:
  4. CustomAction elements are used to add command buttons and other elements to the user interface. The Location attribute dictates where the commands will be added. Since our custom tab will be added to the ribbon, we’ve used the location CommandUI.Ribbon CustomActions can optionally be bound to list types; in our example, we’re using type 101, which refers to the Document Library list type. You can also bind a custom action to a specific content type.

  5. Within the CustomAction element, add the following code:
  6. We’re creating a Tab element. Because we want to add a new tab to the ribbon, we’re setting the Location attribute of the parent CommandUIDefinition element to Ribbon.Tabs._children. If we were adding a group to an existing tab or a control to an existing group, we’d set the Location to an appropriate value such as Ribbon.ListItem.New.Controls._children to add a control to the New group in the ListItem tab.

  7. Within the Tab element, add the following code:
  8. We’re performing two actions in this step. First, we’re specifying how the groups within our tab should scale. For each group, a MaxSize and a Scale element should be added to the Scaling group. The MaxSize element defines the default template that should be used when there are no space constraints. The Scale element defines the template that should be used when there is insufficient space to display the template reference in the MaxSize element.

    The second action that we’re performing is to define the groups that make up the tab. Each Group element has a Template attribute that is used to specify the template that will be used to lay out the group controls within the ribbon.

  9. Within the Controls element, add the following code:
  10. This addition is relatively straightforward: we’re adding a button control to our group. One thing worth noting is the TemplateAlias attribute; as you’ll see, this value is used to hook controls up to positions within the template that’s specified in the Group element.

  11. After the CommandUIDefinition element, add the following code:
  12. In this section, we’re defining a template for use by our custom group. Things to notice in this snippet are the TemplateAlias attributes, which are used to hook up the ControlRef elements in the template to the actual controls in the group. Also notice the two layout elements; each template can contain multiple layout elements. Effectively, a template is a collection of layouts, and groups can be bound to a maximum of two layouts: one layout to use when there are no space restrictions and another to use when space is restricted.

  13. We can now deploy our customization. Choose Build | Deploy Chapter3. Using the browser, navigate to the demo site that we created earlier, and from the navigation pane select the MyCustomPages document library. Our new tab will be visible within the ribbon, as shown:

Extending the Ribbon
Handling Events from the Ribbon

You’ve seen how to add a control to the ribbon declaratively. However, the control we added doesn’t do anything useful. Let’s look at how we can handle events that are generated from our ribbon customizations. As mentioned, a predefined number of controls can be added to the ribbon.

If we look at the ColorPicker control, we find that the following attributes are defined:

• Command This attribute is used to specify a command that should be executed when the control is clicked. This attribute is present on all ribbon controls.
• CommandPreview This attribute is used to specify a command that should be executed for previewing a color selection.
• CommandRevert This attribute is used to specify a command that should be executed to revert a preview command.
• QueryCommand This attribute is used to specify a command that should be executed to retrieve state information. In a sense, these attributes allow us to hook up event handlers for whatever events are defined by the control. Since the ribbon is primarily generated on the client side, handling events must also take place using client-side scripting. In the case of the ribbon, this is commonly done using JavaScript and the Client Object Model. To see how this works in practice, let’s add an event handler for our button control.

  1. To the Button element in the Elements.xml file, add the following attribute:
  2. <Button Id="Chapter3.FirstDemoGroup.HelloWorld"Command="Chapter3.HelloWorldCommand" Sequence="14" Image16by16="/_layouts/images/NoteBoard_16x16.png" Image32by32="/_layouts/images/NoteBoard_32x32.png" Description="Displays a Hello World message" LabelText="Hello World" TemplateAlias="c1"/>
  3. After the closing tag of the CommandUIDefinitions element, add the following element:

The Command attribute (and any other event handling attributes on a control) contains a reference to a CommandUIHandler element. The CommandUIHandler then defines the action that should be taken when the event is raised. In this simple example, we’re executing some inline JavaScript to show a notification message using the Client Object Model.
Deploy the revised solution. If all is well, clicking the Hello World button will show a message using the Notifications framework, as shown here:

Notifications framework
Disabling Controls

Earlier you saw that controls on the ribbon can’t have their visibility toggled for usability reasons. When a command cannot be used, best practice dictates that it should be disabled. Let’s look at how we can add this functionality to our button command. On our CommandUIHandler element, add the following attribute:

This simple example periodically disables the button depending on the current time. The EnabledScript attribute should refer to a script that returns a Boolean value. One thing that this example highlights is that the script specified in EnableScript is called only when users click controls in the user interface.

Complex Event Handling
The preceding examples have shown you how to handle events using embedded JavaScript; although this works well, as the JavaScript becomes more complex, it gets increasingly difficult to manage. A common approach to dealing with this problem is to maintain scripts as separate files. Let’s look at how we can use external scripts when handling events.

Adding Script Links Using a Delegate Control
The first thing that we need to do when using external scripts is to find a way to add a link to the script to our page. The best method to achieve this is to use a delegate control. Delegates are covered in more detail in—but for now it’s enough to know that a delegate can be used to override certain parts of a SharePoint page. The out-of-the-box master page that ships with SharePoint 2010 includes a delegate control named AdditionalPageHead in the page header. By adding our own content to this delegate, we can add references to our external scripts.

  1. The easiest way to implement a delegate control is to add a user control to the %SPROOT%/TEMPLATE/CONTROLTEMPLATES folder. This folder is mounted on all SharePoint sites as /_ControlTemplates/, and user controls contained here can use code-behind in assemblies that are stored in the Global Assembly Cache (GAC). To add a new user control, choose Project | Add New Item. Select User control in the Add New Item dialog and set the name to CustomRibbonHeader.ascx, as shown next:
  2. Adding Script Links Using a Delegate Control

  3. The new user control will be placed in the ControlTemplates/Chapter folder by default. In the CustomRibbonHeader.ascx file, add the following markup:
  4. This code snippet uses ScriptLink controls to ensure that all required scripts are loaded. SP.js contains core functions for the JavaScript Client Object Model, whereas CUI.js contains functions necessary for the operation of the ribbon.

  5. In the Elements.xml file containing our CustomAction element, add the following element after the closing tag of the CustomAction element:
  6. This code hooks up our delegate control to the AdditionalPageHead delegate.

  7. Since the whole purpose of adding a delegate control is to include a link to our custom external script file, our next step is to create the file. Select the Chapter3 project node in the Solution Explorer pane, and then choose Project | Add SharePoint Layouts Mapped Folder.
  8. Add a new JavaScript file into the LayoutsChapter3 folder named Chapter3. PageComponent.js. The final ScriptLink control in the preceding code snippet will ensure that a reference to this file appears on the page.

Creating a Page Component
A page component is effectively a JavaScript code-behind file for our ribboncustomization. Page components are derived from the CUI.Page.Page Component class that can be found in cui.js, the out-of-the-box JavaScript file that is concerned with delivering the core functionality of the ribbon.

TIP Many script files used in SharePoint have a debug version that is easier to read. These files commonly have a .debug.js extension, such asCUI.debug.js. By creating a custom page component and overriding the appropriate methods, we can encapsulate the event handlers for our tab in a separate file. Follow these steps to create a simple page component to support the demo tab that we added earlier.

  1. PageComponent.Js file that we created earlier, add the following code:
  2. This script defines a new class. PageComponent, which inherits from CUI.Page.PageComponent. By using this object, we can add all of our event handling code within a separate file rather than having everything contained within the CommandAction attribute of CommandUIHandler elements. The getGlobalCommands method returns a list of the commands that are supported by the page component—in our case, we’re supporting only one command. The canHandleCommand method is used to specify whether an item should be disabled or not, and the handleCommand method is where we can add the actual implementations for our event handlers. Commonly, these will take the form of method calls.

  3. Since we’re no longer using the inline script in our CommandUIHandler element, replace the attribute as follows:
  4. To initialize our custom page component, add the following JavaScript to the CustomRibbonHeader.ascx file after the ScriptLink controls:

We’re now ready to deploy the revised solution. This time, clicking the Hello World button will return the message specified in the.PageComponent.js file.

Server-Side Event Handling

So far, you’ve seen how to add ribbon customizations and handle events using inline JavaScript as well as via a custom page component. While this is very much the recommended approach, for some functionality, access to the Server Object Model may be a requirement. As well as creating page component files and manually writing JavaScript to handle our events, SharePoint 2010 also provides server-side objects that can be used to add command to an existing custom page component. We’ll add a new button for the purposes of this demonstration.

  1. In the Elements.xml file, add the following Group element after the closing tag for the existing Group element:
  2. So that the new group will display properly, we need to add a Scaling/MaxSize element. Between the existing MaxSize and Scale elements, add the followingelement:
  1. Add the following code to the CustomRibbonHeader.ascx.cs file:
  2. Make the following modification to the Chapter3.PageComponent.js file:
  3. Deploy the revised solution. The Chapter 3 tab will now contain two buttons: When the first button is clicked, a notification will be displayed as before. When the second button is clicked, the name of the current list will be updated to include a time stamp, confirming that our server-side code is being executed.In this sample, we’ve used the SPRibbonPostBackCommand to create a command programmatically that emits the JavaScript code necessary to perform a server post back. When using this technique, bear in mind that a custom page component is required.The page component must make calls into the base classforgetGlobalCommands, commandEnabled, and handleCommand to hook up the server side event handler properly.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Share Point 2010 Topics