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.
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.
Each tab can contain many controls. So that these controls can be further grouped into logical categories, individual controls must exist within a group.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Deploy the revised solution. If all is well, clicking the Hello World button will show a message using the Notifications framework, as shown here:
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
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.
This code hooks up our delegate control to the AdditionalPageHead delegate.
Creating a Page Component
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.
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.
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
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.