El bienestar integral en los adultos mayores

Throughout this book, and especially in this chapter, we have been mentioning that there is no migration of your existing MOSS 2007 master pages; instead, you have to rewrite and design them from scratch again. You have already seen the changes related to visuals, master pages, CSS, and the ribbon. Now, we will discuss how your existing artifacts can be migrated, leaving the design part for new custom development. Your existing master page artifacts might be some of the following (all with respect to your branding of course):

• Custom CSS

• Custom JavaScript, jQuery, and Ajax files

• Images, banners, logo files, and so on

• Web controls that are part of the master page

• SharePoint features that take care of applying the master pages or staple them when a site collection or site is provisioned

There might be other assets, but the preceding ones are the primary areas that branding artifacts usually fall under. When you build your project structure in Visual Studio 2010, mappings to features and the layout folder are now built in, so you don’t need to create a structure (see the Visual Studio section in Chapter 4 for more information). In this chapter, we will cover some high-level aspects of migrating branding artifacts. All of the listed artifacts could be re-created in the same structure you have been using so far. Usually, these files are deployed to the layouts folder with specific project folder unless there is a special need to add them under site document or asset libraries. This means that all custom assets would be deployed under _layouts, as in the following examples:

• _layouts/{brandingspecificfolder}/styles/: Where styles are deployed

• _layouts/{brandingspecificfolder}/images/: Where images and logos are deployed

• _layouts/{brandingspecificfolder}/scripts/: Where custom scripts (jQuery or JavaScript) are deployed

And master pages, of course, will be part of the SharePoint 2010 resource files that will be added to the feature elements file. All other web controls will be either added to the control templates folder or will composite controls that are deployed to either the global assembly cache (GAC) or bin.

Though you can design your master pages by editing the out-of-the-box v4.master file using SharePoint Designer, we wouldn’t recommend doing so. It’s a best practice to write your custom master page and deploy it as a feature, rather than editing the master pages, directly unless or otherwise required or suggested by your architects.

You may have already noticed some of the visual changes. A couple more interesting things you need to keep in mind while designing master pages are explained here. First, the dialogs that appear as part of some of the actions you perform might contain a number of visual aspects that you don’t want to display on the branding, especially when it comes to the dialogs. For example, top navigation is one control that would look very odd and clumsy on a dialog box. To avoid displaying any of the elements in the master page, you can simple add the following CSS tag to restrict the specific control or tag under the dialogs. For example, to hide a custom control on a dialog, you would do as follows:

<div class="s4-notdlg">

// Your Custom Control Tag Goes Here </div>

You can use the same tag with other elements, as shown here: <div id="s4-leftpanel" class="s4-notdlg">

// Quick Launch </div>

The preceding example is very specific to the quick launch feature that you would notice under the default v4.master page.

Next, in case of fixed-width design, you need to add a specific class s4-workspace. Locate it in the master page, and add the s4-nosetwidth CSS class, as follows. If you do not set it on an out-of-the-box master page, the page would use 100 percent width.

<div ID="s4-workspace" class="s4-nosetwidth">

The location of the master pages in SharePoint 2010 hasn’t changed. All the out-of-the-box, as well as custom, master pages are deployed to the _catalogs/masterpage library. Once you finish designing your master page based on the starter master pages (or other mechanism you wish to choose) and following the CSS script changes that are mentioned earlier, you can begin designing your features that deploy these master pages to the _catalogs/masterpage location. You can refer to the final project structure, as shown in Figure 3-19.

CHAPTER 3  BRANDING AND DESIGN CHANGES

Figure 3-19. Build master page structure in Visual Studio 2010

You will have the following items in the project specific to the branding aspects:

• Layouts mapped folder, with specific folders for images, scripts, styles

• Resource folder (ProMigrationResources in this case) for your master page and its elements file

• Feature and feature receiver code to add the master page on activation or retract and apply the v4.master file when a feature is deactivated

• Specific web events receiver that would work as a feature stapler to attach the master page

You will have to map your existing files as shown in Figure 3-19. Let’s now observe the contents under each of these assets. The elements file will look like Figure 3-20. Module and File elements are not new, but notice the Property Name UIVersion that is set to a value of 4. This specifies that the deployed master page is version 4, that is, a SharePoint 2010 master page.

Figure 3-20. Code for the elements file

Under the event receiver, again the code logic is not special. Feature activation and deactivation events have not changed, as shown in Figures 3-21 and 3-22. You can use the CustomMasterUrl property to define the master page for a publishing site.

CHAPTER 3  BRANDING AND DESIGN CHANGES

Figure 3-22. Master Page feature deactivation code

The feature stapling aspects in SharePoint 2010 have also changed. Though the feature stapling concept still exists, it’s kind of obsolete, and the recommended approach is to use web event receivers. To add one such event, on a Visual Studio project, add a new event receiver. Under the customization wizard (shown in Figure 3-23 ), select Web Events; select the “A site was provisioned” event handler, and click Finish.

Figure 3-23. Creating web events

Once the corresponding event receiver class is created, under the WebProvisioned event, add the code shown in Figure 3-24. This event will fire whenever a new site is provisioned and apply the master page that has been choosen in the code logic.

CHAPTER 3 BRANDING AND DESIGN CHANGES

Figure 3-24. Web provisioned event handler

■Tip For more information specific to creating master pages, see

.

Summary

In this chapter, we have looked at the following (see Figure 3-25):

• Overall visual changes in themes, master pages, CSS, and jQuery customizations

• The evaluation and rendering of publishing templates

• Changes to the WCM web parts, particularly around the Content Query, Content Editor, XML Viewer, and XSLT List View web parts

• SharePoint 2010 compliance with WCAG and ARIA

• Ribbon customizations and branding your ribbon

• Migrating your existing branding artifacts

Figure 3-25. Developer Roadmap in SharePoint 2010

In the next chapter, you will learn some very good enhancements in SharePoint 2010 for savvy business developers and .NET developers. We will discuss SharePoint 2010 Designer changes and new enterprise content management (ECM) features from a business developer standpoint, as well as Visual Studio 2010, ribbon, and API changes from a .NET developer standpoint.

C H A P T E R 4