EXERCISE 5-5. IMPLEMENTING A SIMPLE DYNAMIC MENU
13. Once you’ve edited both pages click the Preview in Browser button in the Preview
Figure 5-11. Page with dynamic JavaScript–based hyperlink menu
Interacting with Data
One of the most common uses for SharePoint is to display information stored in lists and libraries.
Simply create your list or library either from one of the preloaded types or from your own custom set of
columns. Then add a web part to the page, and you can view the content you add to the list or library.
You can even easily control which columns are displayed by editing the view.
But what if you want to improve the formatting of the content displayed in the web part? You might want to apply more extensive sorting and filtering than you can simply by editing the view. Or maybe you want to highlight specific fields or rows of content dynamically based on the value of the content.
These kinds of tasks go beyond what can be accomplished through the UI and require more extensive customization.
In SharePoint Online, the web parts used to display content from lists and libraries are all based on Extensible Stylesheet Language Transformation (XSLT) code. One way to change the default display is to replace the Extensible Stylesheet Language (XSL) used by the web part with your own custom code. But in many cases, this is a time-consuming development task that might not be necessary. With SPD 2010, you can easily modify the XSL in these web parts to create dynamic UIs for your content without having to write custom code. Using just SPD you can create dashboards that highlight important information, design custom forms tailored to individual roles, and customize the available toolbars and Server ribbon commands associated with the data.
Customizing List and Form Views
In SharePoint 2010, the contents of lists and libraries are displayed using XSLT–based web parts called List View or List Form web parts. List View web parts display items in a grid, while List Form web parts display the metadata fields of an individual item. List View web parts are the basis for the default page used to display a library and are also the default when adding a list or library to an existing page. List Form web parts are primarily used as the basis for the New, Edit, and View forms associated with a particular list, library, or content type.
XSLT List View web parts can be modified relatively easily using just the browser interface. This includes the ability to substitute completely custom XSL which can radically change the display of the content. But this requires an understanding of XSL coding. Using SPD, you can accomplish similar customizations more easily using commands in the ribbon. To customize an existing list view, just select the web part on the page in SPD. You will see a new set of contextual tabs that provide customizations for the web part. Table 5-2 highlights the various ways you can customize an XSLT–based List View web part in SPD.
Table 5-2. List View Web Part Customizations in SPD 2010
Customization Explanation
Add or remove columns You can add, remove, or arrange the order of columns in the view.
Filter data You can filter the data in a list by showing only the items that meet a certain criteria. You are not limited to only two filters as you are in a regular view.
Sort and group You can sort or group the data in a view.
Apply different view styles You can select a different layout for the view from a predefined list of view styles.
Apply conditional formatting You can modify how rows, columns, or cells are formatted or displayed based on conditions in the data being presented.
Create a formula column You can create a calculated field that displays the result of a calculation based on other columns.
Change the paging You can modify the paging settings to change the number of rows on a page or the total rows returned.
Display data from multiple sources
You can link two or more related data sources and display them in a single view.
Use asynchronous updates You can enable the use of AJAX so that the view can be updated asynchronously without refreshing the entire page.
Add parameters You can create and pass parameters to a view to allow for more user interaction with your view at runtime.
Use HTML, ASP.NET, and SharePoint controls
You can bind a variety of other controls to the data source to customize the formatting of your view.
Data View and Data Form Web Parts
Although XSLT List View web parts are the default for displaying lists and libraries in SharePoint Online, Data View and Data Form web parts are also still available. Customization of Data View and Data Form web parts in SPD is the same as it is for XSLT List View and List Form web parts. But the Data View and Data Form web parts can be used for any data source, while the List View and List Form web parts are available only for content displayed in the form of a SharePoint list. Table 5-3 summarizes when SharePoint uses each type of web part, what data sources they are used with, and some of the advantages/disadvantages associated with their use.
Table 5-3. Web Part Usage, Advantages, and Disadvantages Web Part Data Sources Advantages/Disadvantages XSLT List View
Web Part (XLV)
SharePoint lists SharePoint libraries External Lists
The default web part used to display SharePoint lists and libraries Cannot be used with external data sources other than in the context of an external list
XSLT List Form Web Part (XLF)
SharePoint lists SharePoint libraries External Lists
Used as the default form for viewing a single list or library item Only customizable using code view in SPD
Data Form Web Part (DFWP)
Any Data Source The default web part used when creating a view from a data source in SPD
Can be used with any kind of data source
Implementing InfoPath Forms
By default, SharePoint Online displays content from lists and libraries with a set of four built-in ASPX forms that make use of either a List View or List Form web part. But these forms can be replaced by InfoPath-based forms. The forms will still be ASPX pages, but the pages will now contain an InfoPath Form Web Part (IPWP) in place of the XSLT List View or Form View web part. InfoPath 2010 can then be used to customize these web parts by adding rules, conditions, formatting, and branding. Once they are completed, you can use SPD to select them as the default form for the various list actions: adding, editing, or displaying list content. The InfoPath forms behind IPWPs can only be edited in InfoPath.
When viewed in SPD they will display as shown in Figure 5-12.
Figure 5-12. InfoPath Form web part displayed in SPD 2010
Creating Custom Ribbon Actions
So far in this section, we have focused on customizing the display of content in SharePoint. But using SPD there are also some easy ways to add custom ribbon actions that are associated with specific lists and libraries in a site. There are three types of custom actions that can be added in the List or Library summary page in SPD:
• Navigate to form: Used to navigate to one of the existing List or Library forms to display, edit, or add an item. You can navigate to either a regular or InfoPath- based form.
• Initiate a workflow: Initiate one of the workflows associated with this particular list or library.
• Navigate to a web URL: Navigate to any other SharePoint or external URL.
Interacting with External Data
One of the challenges that you will face when moving to Office 365 is that not all your data will be stored inside SharePoint Online. A lot of the data that your organization depends on will be stored in line-of- business (LoB) systems such as Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) systems. The information in these systems is stored externally to SharePoint, but it is often critical that you display the data inside SharePoint. In on-premise installations, this gap is often filled by SharePoint BCS. But BCS support was missing from the original rollout of Office 365. Limited support for BCS was added to SharePoint Online beginning with Service Update1 (SU1) that was applied in November 2011.
Business Connectivity Services (BCS)
Microsoft Business Connectivity Services (BCS) provides support for reading and writing data stored in external systems from within Microsoft SharePoint 2010. In earlier versions of SharePoint, BCS was known as Business Data Connectivity (BDC). Using BCS developers can rapidly build solutions using SPD 2010. Using SPD you can define BCS models, connect to external data, and interact with that data inside SharePoint as though it were a SharePoint list.
Business Data Catalog (BDC)
Business Data Catalog (BDC) was the name given to the service in Microsoft Office SharePoint Server 2007 designed to provide read-only access to external data systems. BCS provides richer integration, including full read/write access to external data in SharePoint 2010. Many of the concepts and artifacts available in BDC, like profile pages and BDC web parts, are now available in BCS. As a result, the terms BCS and BDC are often confused.
Supported External Data Sources
In an on-premise SharePoint installation you can use SPD to configure three different types of
connections in BCS. The three types of connections are a Windows Communication Foundation (WCF) service, a .NET class, or a Microsoft SQL database. The support added to SharePoint Online in SU1 includes only support for WCF service connections. Connecting directly to a SQL database might be supported in a future update. Support for .NET class connections will probably never be provided because SharePoint Online is limited to deploying .NET classes as sandboxed solutions.
Note BCS WCF support is not backward compatible with .NET 2.0 XML Web Services when using SPD 2010.
The Secure Store Service
One of the challenges when building a BCS connection to a WCF data source in SharePoint Online is how to handle authentication. Most external data sources will not be using the same claims-based authentication as SharePoint Online. This is where the Secure Store Service (SSS) proves useful. The SSS provides a credential cache that maps the identities of SharePoint users, SharePoint groups, or security groups to credentials that are stored in an encrypted database. When the BDC model needs to use external credentials to access a data source, it passes the identity of the user to the SSS. The SSS then returns the external credentials that are mapped to that user or group and uses them in the WCF service call.
Credential mappings stored in the SSS are organized by target applications. Each target application is identified by a unique target application ID. The target application includes credential fields for a username and password, a group of users who can administer the application settings and a group representing the users or groups who can use the credentials. Each BDC model in BCS is configured to use credentials from a particular target application. The Secure Store service in an on-premise
SharePoint installation can support multiple sets of credentials per target application, each mapped to a specific user or group. But in SharePoint Online there can be only one set of credentials per target application.
Note The Secure Store Service (SSS) in SharePoint Online only supports Group Restricted target applications.
Individual and regular group credentials are not supported at this time.