Hello all, Stephen here again. Awhile back I recorded a series of workflow videos that were posted on Office Online:

Watch this: Design a document review workflow solution

Many of you have submitted comments asking if I could make available both the Visio diagram shown in the videos and the solution itself.

I’m happy to oblige (and apologies for the delay), so please find attached to this blog post a .zip file containing the site template (.stp file) and Visio diagram (.vsd file).

A few notes:

• The solution uses the Document Center site template found in SharePoint Server 2007 (not Windows SharePoint Services), so it must be deployed to a SharePoint Server environment.
  
  
• The site template includes WorkflowDashboard.aspx, but the Data View on that page must be re-created by following the steps in the Part 12 video and the Part 13 video.
  
  
• The URLs used in the e-mail messages in the workflows must be updated to reflect the path of the new site, as mentioned in the Part 14 video.

Hope you find this helpful.

Hello all, Stephen here again – I’m a writer for SharePoint Designer. As you know, SharePoint Designer 2007 is a powerful tool for editing SharePoint sites — so powerful, in fact, that you likely have scenarios in your organization where you want to control where and how people can use SharePoint Designer 2007.

With this post, I’ll try to answer a very common question: “How can I lock down SharePoint Designer in my organization?” And I’ll try to answer the flip side of this question, which arises in an environment where SharePoint Designer has been locked down and the user asks: “Why do I see this message when I attempt to edit a site in SharePoint Designer?”

Options for locking down SharePoint Designer

The following table outlines the various ways in which you can lock down SharePoint Designer in your organization. Some of this information has been previously published in various venues (Office Online, TechNet, MSDN, Knowledge Base, etc.), but I thought it would be helpful to pull it all together for you.

For a visual overview of the various levels, see MSDN: Server and Site Architecture: Object Model Overview.

Permissions overview

For the above options that use permissions, whether at the site level or in Central Administration, there are three permissions that you need to consider.

Option 1 — Disable the Add and Customize Pages permission

If you are concerned about users editing files in a site, you can clear the check box for Add and Customize Pages. Doing this also clears the check box for one dependent permission, Manage Web Site.

When you remove these permissions, users can still open a site in SharePoint Designer, and they can open and edit pages that may be at the root of the site, such as default.aspx. But when they try to save these changes, they see this message.

Without the Add and Customize Pages permission, a user cannot save the edited page to the root of the site or to any folders in the site — for example, a user cannot save changes to default.aspx at the root of the site. But they can save the edited page to any library in the site to which they have permissions or to a location outside the current site. Remember that list permissions are separate from site permissions — in fact, these two sets of permissions have separate sections in the list of permissions. So preventing users from saving changes to files that reside outside of lists or libraries does not prevent them from opening the site in SharePoint Designer and doing things like deleting workflows from the Workflows document library or deleting an entire list. Permissions for these lists and libraries are managed separately (see the next section).

Here’s another consideration: If you have all of the permissions (the default Full Control permission level), you see all options on the Site Settings page (below, top image). If you do not have the Manage Web Site permissions (dependent on Add and Customize Pages), many options on the Site Settings page are trimmed away (below, bottom image). So take this into account when managing user permissions, especially at the level of Central Administration, because you may be preventing many people from performing key administrative tasks in their site.

Option 2 — Disable the Manage Lists permission

As mentioned above, if users can open a site in SharePoint Designer, they can — depending on their list permissions — delete content in lists and libraries such as workflows, list forms, or even entire lists. To prevent this, you must disable the Manage Lists permission.

After you remove this permission, when a user opens a site in SharePoint Designer and tries to delete a list (or a file in the list) that is inheriting permissions from the site, they see the standard “Access denied” warning message.

Note that this permission can be overridden at the level of a specific list or library if that list or library breaks inheritance. For example, the Workflows document library is a hidden library in the site that by default does not inherit permissions from the site. When you create a site, the Workflows library gets the same permissions configuration as the site, but any permissions changes that you subsequently make at the site level — such as disabling Manage Lists — do not automatically trickle down to the Workflows library.

To manage permissions for the Workflows library, open the site in SharePoint Designer >> right-click the Workflows library >> click Properties >> click the Security tab >> click the link “Manage permissions using the browser”.

Note that disabling Manage Lists for users also prevents them from adding columns to a list or creating public views.

Option 3 — Disable the Browse Directories permission

The previous options prevent users from editing or deleting objects in a site after they open the site in SharePoint Designer. You can also prevent users from opening a site in SharePoint Designer in the first place by disabling the Browse Directories permission.

Disabling this permission also disables four dependent permissions: two discussed above (Add and Customize Pages and Manage Web Site) plus two more, Manage Permissions and Enumerate Permissions.

When a user who does not have the Browse Directories permission for a site (or Web application) tries to use SharePoint Designer to open that site (or any site in that Web application), they see this message.

Then they are presented with the prompt for new log-on credentials. If the new credentials fail, they see this message.

Not an option — Disable the Use Remote Interfaces permission

Looking at the list of permissions, you may be tempted to disable the Use Remote Interfaces permission because it mentions using “SharePoint Designer interfaces to access the Web site” — a reasonable conclusion, but just don’t do it! This permission has a dependent permission, Use Client Integration Features, and removing this permission disables all SharePoint integration with Office programs like Word, Excel, and PowerPoint.

For example, if you disable Use Remote Interfaces, you’ll notice that the Edit in Microsoft Office Word option disappears from the item menu in a list or library.

Or when you try to view the version history of a document in Word (Office button >> Server menu >> View Version History), you see this message.

And all sorts of other cool features like workflow integration get disabled, so disabling Use Remote Interfaces is not the way to control access with SharePoint Designer.

At the server level per site definition — ONET.XML

If you are a server administrator, you can prevent users from opening sites in SharePoint Designer 2007 by modifying the ONET.XML file on the server. Every site definition includes an ONET.XML file, and changing this file will affect all sites based on that site definition. For example, you can modify ONET.XML for the “sts” site definition, which will prevent all users from opening in SharePoint Designer all team sites created from this site definition. There is no “uber-ONET.XML” file that controls all site definitions.

Changing ONET.XML is a global change that affects all sites on the server.

1) On the server, open Windows Explorer and browse to the folder that contains the site definition:

<Drive:>\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\<site_type>\XML

Here are the site templates for a server running SharePoint Server 2007. Windows SharePoint Services has fewer site templates. Each site template has its own ONET.xml file.

Some of the folder names are a bit cryptic – for quick reference, this table maps them to site names.

2) Right-click the ONET.XML file for the site definition and open it with Notepad.

3) Add the following line inside the opening Project tag:
DisableWebDesignFeatures=wdfopensite

4) Save the file and close Notepad.

5) On the server, do an iisreset.
(Click Start, click Run, type cmd, click OK. At the command prompt, type iisreset computer_name /restart, then press ENTER.)

6) If you have a site of this type open in SharePoint Designer, close SharePoint Designer.
When you try to open the site in SharePoint Designer, you should see the following message.

For more information

Knowledge Base 940958: How to prevent SharePoint Designer 2007 users from changing a Windows SharePoint Services 3.0 site or a SharePoint Server 2007 site

TechNet: Special directories and storage locations (Office SharePoint Server)

MSDN: Site Definitions and Configurations

MSDN: Project Element

At the Web application level for all users — Central Administration permissions

In Central Administration, you can enable or disable permissions for all users and groups in a Web application. Managing permissions centrally like this can be convenient because a Web application can contain 150,000 site collections. When you clear the check box for a permission in a Web application, that permission cannot be assigned to any user or group in any site in any site collection in the Web application.

Browse to the Central Administration site. On the Application Management tab, click User Permissions for Web Application.

On the next page, you see the same list of permissions that you see when you manage the permission levels for an individual site (with one exception: in Central Administration there’s an additional permission named Use Self-Service Site Creation).

The effects of disabling specific permissions are discussed above, but in Central Administration the simplest way to prevent uses from editing sites in SharePoint Designer is to disable the Browse Directories permission so that they cannot open sites at all in SharePoint Designer — with the caveat that these people therefore won’t have access in the browser to all options on the Site Settings pages and won’t be able to manage permissions for any site in the Web application.

For more information

TechNet: Manage permissions for a Web application (Office SharePoint Server)

At the Web application level per user or group — Central Administration policy

The option covered in the previous section — permissions for the Web application — is a blanket setting that covers all users and groups for all site collections in a Web application. If you need finer granularity, you can set permissions for specific users or groups in a Web application. You do this by creating a policy for the Web application. Joel Olson’s blog has some good examples of when a Web application policy is useful.

And as Joel mentions, policy for a Web application is a way to centrally manage permissions and is different from an information management policy — auditing, expiration, labels, barcodes — that you use to manage data in a list or library.

Browse to the Central Administration site. On the Application Management tab, click Policy for Web Application.

Managing permission policies in Central Administration is much like managing permissions in a SharePoint team site. You can add users, configure permission levels, and then assign users a permission level.

Except the trick with setting permissions in a policy is that there are two check boxes for each permission — Grant and Deny. If you leave both check boxes blank, this means the policy does not explicitly grant or deny this permission, so it’s up to the discretion of site owners in the Web application whether users have this permission. If you explicitly grant a permission as part of a Web application policy, that user has the permission and this cannot be overridden by a site owner at the site level. Likewise, explicitly denying a permission prevents users from ever having this permission.

Your choices here for using permissions to lock down SharePoint Designer are the same as noted above. For quick reference, this table shows which default policy permissions levels grant or deny these permissions. The simplest path here to locking down SharePoint Designer would be to add a new permission policy level that explicitly denies Browse Directories (with the caveats about dependencies noted above), and then assign that policy to specific users or groups.

For more information

TechNet: Manage permissions through policy (Office SharePoint Server)

At the site level per user or group — Site permissions

A site owner can set permissions on a per user and per site basis.

If the site is not inheriting permissions:

· Click the Site Actions menu >> Site Settings >> Advanced Permissions >> Settings menu >> Permission Levels

If the site is inheriting permissions:

· Click the Site Actions menu >> Site Settings >> Advanced Permissions >> Actions menu >> Edit Permissions >> click OK >> Settings menu >> Permission Levels

At the site level, the same permissions are available to you, and they have the same dependencies noted above. For quick reference, this table shows which default permissions levels in SharePoint Server 2007 include these permissions.

The simplest guidance here is:

· To prevent users from opening a site in SharePoint Designer, add them to the Visitors group. Note that Visitors also cannot edit items or files in lists or libraries in the browser.

· To prevent users from editing a site in SharePoint Designer, add them to the Members group. Members can edit items or files in lists or libraries in the browser. They can also open (but not edit) a site in SharePoint Designer.

· To allow users to edit a site in SharePoint Designer but not perform site owner–type tasks (such as managing permissions), create a Designers group and assign that group the Design permission level. Users with the Design permission level can open and edit a site in SharePoint Designer, but they do not have the Manage Permissions permission.

Remember that permissions at the site level are overridden by permissions at the Web application level. Even if you assign a user the Full Control permission level for your site, that user will get denied access if the required permissions have been removed or denied in Central Administration.

For more information

Office Online: Permission levels and permissions

Office Online: Manage permission levels

At the site level per user or group (not a security feature) — Contributor Settings

You can use the Contributor Settings feature to enable and configure Contributor mode, which is a limited access mode in SharePoint Designer 2007. Users who open a site for editing in SharePoint Designer 2007 have access to different commands or features, depending on which Contributor group they belong to and what editing restrictions have been assigned to that Contributor group.

On the Site menu, click Contributor Settings.

Contributor Settings provides fine-grained control over which users can perform which tasks in SharePoint Designer 2007. But keep two important points in mind:

· Unlike permissions, Contributor Settings is not a security feature. Contributor mode is designed to be used in an environment where site owners are confident of their users’ intentions. Contributor mode helps to guide users in a particular direction to carry out their tasks, and this guidance prevents accidental changes to the Web site.

· A user’s Contributor Settings cannot override what their permissions allow them to do. Permissions are a security feature; Contributor Settings are not a security feature; if the two conflict, permissions always trump Contributor Settings.

To turn Contributor Settings on or off, you must have the Manage Permissions permission. In SharePoint Server 2007, by default only the Full Control and Manage Hierarchy permissions levels include this permission. So by default, only people in the Owners group can turn off Contributor Settings.

Finally, if a user tries to save a file to a location that is disallowed by their Contributor Settings, they see the usual “Access denied” message.

Contributor Settings can only be configured on a per-site basis, and these settings are stored in an .htm file. However, you can configure these settings on a temporary site, save the .htm file, and then include this file in a site definition by using the File element. This way, all sites created from this site definition will share the same Contributor settings.

For more information

Office Online: Introduction to Contributor Settings

Office Online: Use Contributor Settings as a site manager

Per user or per computer — Group Policy

In a Windows-based network, administrators can use Group Policy settings to help control how users work with the 2007 Microsoft Office system, including SharePoint Designer 2007. Administrators can use Group Policy settings to define and maintain an Office configuration on users' computers. Unlike other customizations — for example, default settings distributed in a Setup customization file — policy settings are enforced and can be used to create highly managed or lightly managed configurations. For example, administrators can use policy settings to disable user-interface menu commands and their corresponding toolbar buttons, and keyboard shortcuts.

You can create policy settings that apply to the local computer and every user of that computer, or that apply only to individual users:

· Per-computer policy settings are applied the first time any user logs on to the network from that computer.

· Per-user policy settings are applied when the specified user logs on to the network from any computer.

Group Policy is completely separate from both a permissions policy in Central Administration and an information management policy applied to a list or library. Group Policy does not control access to objects such as sites or site collections in a SharePoint deployment. Instead, Group Policy can disable commands and button in the user interface of SharePoint Designer 2007. For example, if you don’t want users performing resource-intensive tasks such as backing up sites during peak operational hours, you can use Group Policy to disable the Backup Web Site command in SharePoint Designer for specific computers or users.

Disabling UI requires that you specify the toolbar control ID (TCID) for the 2007 Office system controls. For Office 2007 programs that use the Ribbon, this download provides a list of TCIDs.

In SharePoint Designer 2007, you can get control IDs using the same VBA that worked in Office 2003. You can find steps and VBA code snippets at Office Online: Managing Users' Configurations by Policy.

Attachment

For quick reference, the spreadsheet attached to this post lists the TCIDs for all of the menus and commands in SharePoint Designer 2007.

For more information

TechNet: Enforce settings by using Group Policy in the 2007 Office system

TechNet: Disable user interface items and shortcut keys

Enterprise Management with the Group Policy Management Console

Office Online: Managing Users' Configurations by Policy

Hello again, Eray Chou here. We’re hitting the tail end of this year’s conference season, and a question I’ve been asked a few times on the road is whether there are solutions or best practices for rolling back changes to page edits in WSS.

One best practice is to put pages into document libraries and turn on versioning. There are limitations to this solution, which I’ll get into shortly, but it is a quick and easy way to handle changes to page content.

To create a document library in SharePoint Designer:

1.) File > New > SharePoint Content

2.) Click on Document Libraries in the left pane and then select Document Library

3.) Name your Document Library, for example “Pages”, and then click “OK”

Next, turn on Versioning for that document library:

1.) Select the Document Library you just created in the Folder List.
Type Alt+F1 if the folder list is not showing, or click Task Panes > Folder List

2.) Right click on the Document Library and select Properties

3.) Go to the Settings tab

4.) Set the Use Version History option to either “Major and minor (draft) versions” or “Major Versions”. If you opt for the former, set the Make drafts visible to option based on your own preference

Now that your document library with versioning is set up, you can create and save new pages into this document library. Each subsequent save you make will create a new version, and if you make changes that you want to revert, you can roll back to a previous version of the page.

To roll back changes:

1.) Click on the Page you want to roll back in the folder list

2.) Right click on the page and select Version History

3.) Pick the version number to restore, and then click Restore
Note that restoring a version just copies the old content into a new version, so you can always restore your most recent page edits. For example, if I’m currently on Ver 3.1 and decide to restore Ver 2.0, I’ll get a Ver 3.2 with the 2.0 page content.

The Master Pages gallery for your site has this turned on by default. So you can take advantage of rolling back versions on master page edits without additional setup.

As noted earlier, there are a few limitations with this approach:

· This approach does not work for web parts in web part zones. When a web parts is in a Web Part Zone, it gets stored in a different table internally and doesn’t support versioning. This approach does work for web parts that are not in zones.

· We do NOT recommend drag-dropping default.aspx into this document library. The homepage of the site is controlled by a meta-info key, and it takes code to update.

· There is no need to use this approach on Microsoft Office SharePoint Server Publishing sites. Sites using the Publishing template already have a pages library and have this sort of roll-back functionality on by default.

SharePoint Designer 2007 is a ground breaking design tool to help information workers and designers create context rich composite applications without writing single line of code. SharePoint Designer enables many interesting customization and app building scenarios that might not have been originally envisioned by the control developers. Moreover the control preview and persistence mechanism is built on top of the Whidbey control designer framework which is inherently different from the ASP.Net runtime behaviors. That’s the reason sometimes control developers might be surprised to find out controls which work perfectly in browsers might not work at all in SharePoint Designers. Most of the time to fix the issue we need to tweak or redesign the server control in a way that is more compatible with the Whidbey and SharePoint design time framework.

This document tries to summarize some of the best practice of design time friendly server controls to help control developers avoid most common bugs when controls interact with SharePoint Designer. Actually all best practices listed below work well with Visual Studio design surface too so by following the practice we can potentially have the benefit of making our controls work better with VS design areas.

1: Just because a control works in browser doesn’t mean it’ll automatically work in SPD, and usually it’s not SPD or designer framework bug.

SharePoint Designer leverages Whidbey ControlDesigner framework to let WSS server renders control preview for SPD. This process is inherently different from runtime control rendering in many ways:

· When a control is being rendered for design time, the Page context is different from runtime. Many global variables that used to work in runtime doesn’t exist or even will throw uncaught exceptions if we’re not careful. Page.Request is one prime example.

· Control lifecycle is different. Default control designer framework doesn’t call OnPreRender and OnLoad. Only OnInit and Render are guaranteed to be called.

· Control tree structure might be different. Many times controls are added to designer Tree structure in a “flatted out” way, instead of the runtime hierarchical structure.

· In SPD users can update control property in property grid of SPD. This involves SPD sending a remote authoring command to SharePoint server, instantiate the control at server, setting the property, and then gather the markup out of the in memory control at server, and finally sending the markup and preview back to SPD client. This process involves “roundtrip” between markup and in-memory control, unlike runtime ASP.Net parsing which is only one-directional. Because of this complication, the control and its markup requires more from control developers in order for this roundtrip to work seamlessly.

· SPD users can easily drag & drop controls around design surface.

· SPD 2007 can’t run JavaScript code or any other client side code as in browsers. Future releases of SPD might revisit this issue but there’s no guarantee it’ll work next release.

That’s the reason it’s highly recommended that developers verify server control preview fine in SPD and we can update control property through SPD property grid before check in.

2: Make sure Control is self-contained, and doesn’t contain unnecessary client side script.

Since SPD users can easily drag & drop controls around design surface, all server controls have to be self-contained to work in any SPD drop locations. There used to be a server control that spits out <td>content</td> and the markup looks like:

<tr>

<SharePoint:MyControl runat=server/>

</tr>

Obviously this control will generate invalid html once dragged out of the enclosing TR tag and thus needs to be modified to be more self-contained in order for this operation to make sense.

SPD 2007 currently can’t run any client side script code (including VB/Java Script). So any client side script trick to tweak the page content won’t work in SPD. Many of the scripts which are used to update static page rendering are actually avoidable. For instance, we have a control that will use JavaScript trick to add one row in the first table of the page. That same logic could be easily achieved through server side control rendering instead of client side logic. We encourage control developers to avoid unnecessary client side script which will affect static page rendering. This doesn’t apply to any AJAX behaviors which can’t be displayed in SPD.

3: Use SPContext.Current.IsDesignTime or Control.DesignMode. Use them to protect dangerous Page.Request call.

For design time rendering, this.Page is not null since we do have design time Page object available. Unfortunately Whidbey will throw exception for Page.Request call in design time. To protect the exception, we can check SPContext.Current.IsDesignTime which is a global flag. If we’re inside a control object, we can also call the protected method Control.DesignMode to check if we’re in design mode. Those 2 flags are also helpful if control developers want to display special content for SPD design time, just do something like:

protected override void Render (HtmlTextWriter output)

{

If (this.DesignMode)

{

//design time preview goes in here.

}

else

{

// runtime render code goes in here.

}

}

4. Be aware of design time control lifecycle. Use SPControlDesigner or DesignTimeHtmlProviderDesigner for your control if necessary to change control design time lifecycle.

Each server control will be assigned a default control designer by Whidbey. The default Whidbey ControlDesigner doesn’t call OnLoad or OnPreRender to generate control preview. So any server control that relies on logic in OnLoad or OnPreRender will most likely have issues in SPD. Control developers have potentially 2 options to solve the issue:

· Move the logic to OnInit or Render().

· Use a different designer than the default one chose by Whidbey.

To do the latter, control developers can simply add the following line of code as control class attribute:

[Designer(typeof(SPControlDesigner))]

Public class myControl : IDesignerEventAccessor,…

SPControlDesigner is a built in WSS designer which forces the control OnLoad and OnPreRender functions to called. It also makes sure control children expression binding process work, unlike the default ControlDesigner, and IDesignTimeHtmlProvider interface was honored by designer. Since OnInit and OnPreRender are both protected, control designer can’t directly call into those 2 functions. That’s the reason controls that use SPControlDesigner have to implement the trivial IDesignerEventAccessor interface and expose those 2 functions through the interface.

In SharePoint V2, we have IDesignTimeHtmlProvider interface to help FrontPage 2003 get control preview through a SOAP call. However that mechanism is deprecated in Office 2007 so all controls that use IDesignTimeHtmlProvider interface to create preview for SPD won’t really work in designer framework unless you either use SPControlDesigner, or more lightweight designer class DesignTimeHtmlProviderDesigner.

5. Use ParseChildren and PersistChildren attributes if appropriate to facilitate control and its markup roundtrip.

In runtime ASP.Net just parses control markup on the page and then instantiates. In SPD design time users can set control properties through SPD property grid, which involves the complicated process of control instantiation at the server, setting the property and then spit out the true control markup and preview. That whole process requires the control and the markup to “roundtrip”.

Class-level control attributes PersistChildren and ParseChildren dictate how a Web control reacts to any child content within its tags. Child content is the markup that appears between the starting and closing tags for a control's declarative syntax:

<asp:SomeWebControl runat="server" ...>
This content in here is considered the child content...
</asp:SomeWebControl>

The child content can be interpreted in two ways:

1. As property values - many built-in ASP.NET Web controls specify property values as child content. For example, the DataGrid class will specify style information, as well as column information as child content. This actual content maps to properties in the DataGrid class.

<asp:DataGrid runat="server" AutoGenerateColumns="False" ...>

<ItemStyle BackColor="Peach" Font-Name="Verdana" ...></ItemStyle>

<Columns>

<asp:BoundColumn ... />

...

</Columns>

</asp:DataGrid>

2. As children controls - the child content can be interpreted as controls that should be added to the Web control's control hierarchy. The Panel Web control, for example, has the HTML and Web controls that appear within it specified in its child content area:

<asp:Panel runat="server" ...>

What is your name?<br />

<asp:TextBox runat="server" ... />

</asp:Panel>

To indicate which of these two mo7dels should be used, the PersistChildren and ParseChildren attributes are used. By default, the PersistChildren and ParseChildren have values of False and True. The PersistChildren attribute specifies whether Whidbey should persist the child content as children controls. The ParseChildren attribute indicates whether or not the child content should be parsed as properties. So, when PersistChildren is False and ParseChildren is True, the behavior is that inner XML content is treated as property values (again, this is the default behavior). If you want to child content to be treated as child controls in the control hierarchy, you need to explicitly set PersistChildren to True and ParseChildren is False, like so:

[

PersistChildren(true),

ParseChildren(false),

...

]

public class MyControl : WebControl

{

...

}

Because of this constraint, in general we can’t have mixed-up control child content--- it has to be either children controls or property values, otherwise markup and control roundtrip won’t work correctly.

6. Use PersistenceMode(PersistenceMode.InnerProperty) and [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)] attributes, or TypeConverter if appropriate to facilitate control attribute serialization.

As we mentioned in the previous section, a control property can be persisted either as an attribute on the control tag markup, or as control child content. By default Whidbey and WSS designer framework will choose to persists any control property as an attribute on the control tag markup. This means the property text will be encoded inside the attribute. This might turn out ugly in SPD code view. For instance, the Xsl property for DataFormWebPart will be less than appealing if encoded as attribute. To make specific control property persisted as control child tag instead of encoded attribute, control developers can use property-level attribute PersistenceMode(PersistenceMode.InnerProperty) to notify framework.

Many times we have control or Webpart properties that are not of simple types like int, DateTime, Decimal, String, or Guid. Instead it is of complex type that can’t be directly serialized, like SPList. To roundtrip those control properties, control developers have to write its own TypeConverter class which converts between the complex type and string. In TypeConverter implementation we need to implement 4 override virtual functions:

public override bool CanConvertFrom(ITypeDescriptorContext td, Type t); // can the complex type be converted from input type t?

public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType); //can the complex type be converted to input destinationType?

public override object ConvertFrom(ITypeDescriptorContext td, CultureInfo cultureInfo, object value); // convert from simple type value to the complex type.

public override object ConvertTo(ITypeDescriptorContext context, CultureInfo cultureInfo, object value, Type destinationType); //convert from complex type to simple type value.

Of course we might not need to do this at all, since the complex-typed control property might not need to be exposed to SPD at all. This can save all the trouble of creating a custom TypeConverter.

To do that, simply add the property level attribute [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]

7. For advanced control designer developer, be aware of the design time control render peculiarly and control tree structure.

The default Whidbey ControlDesigner behaves unexpected to most runtime control developers in 2 ways:

1. The design time control tree structure is “flattened” by default. This means there’s no guarantee that parent of a control in the runtime is actually the parent in design time. Instead the parent could be a global stub control that is the parent of everything. To many controls this design time behavior is not desired. To control the parenting structure of control tree, developers can use DesignerRegion class to set the desired parent of controls inside the designer region. For more details, please see examples in DataFormWebPartDesigner class.

2. Designer framework calls “GetDesignTimeHtml” method on the ControlDesigner to render the control preview. This call usually happens before the page has finished loading and all controls in the page has been put into the control tree. This could cause problems for controls that need to interact with other controls in the page before doing the preview generation. There’s actually a way to delay the preview render after the page has been loaded in design time. The trick is this line:

SetViewFlags(ViewFlags.DesignTimeHtmlRequiresLoadComplete, true); It has superseded the obsolete virtual function DesignTimeHtmlRequiresLoadComplete in Whidbey.

Thanks,

Robert Chen

Hi everyone, Saiyue Yu here. 

For any field that may be rendered by SharePoint as HTML, you need to disable output escaping. At the code level, this essentially means setting disable-output-escaping = “yes” attribute for the field’s xsl:value-of tag in the Data View. When you do this, make sure that your data source is trustworthy because of the potential security risk for cross site scripting.

Usually the user doesn’t have to worry about output escaping for SharePoint Data Views. Before a Data View is created, Sharepoint Designer retrieves the data types for the selected fields. If a field is Rich Text, which will be rendered as HTML, disabling output escaping is automatically completed.

There are cases when the field schema information is not available, or not considered. The former case can happen when you insert a Data View for a RSS feed. For example, when you create a Data View for New York Times RSS Feed for Education (http://www.nytimes.com/services/xml/rss/nyt/Education.xml, you can do it by clicking MenuBar > Data View > Manage Data Sources to bring up the Data Source Library task pane, and then add the XML file,) the rendering of the description column is Text instead of Rich Text. Because there is no schema information for SharePoint Designer to know that the description column should be rendered as Rich Text, SharePoint Designer renders the column as the fallback type which is Text .

There are also cases when the field schema information is available but not considered by SharePoint Designer, and drag-n-dropping is such a case. For example, you have a Data View to display the food category information from a SharePoint List. When you created the Data View, you chose to show only CategoryID and Title columns. Later you decide to add the Description field, and it is done by adding another column to the Data View and drag-n-dropping the Description field from the Data Source Details Task Pane. Although the data type for the Description field is Rich Text and the schema has this information, but since the schema information is not considered in the drag-n-dropping situation, the rendering of this Rich Text field will contain escaped sequence like &amp;:

To correct the rendering, you can bring up the Common xsl:value-of Tasks dialog for the field, and choose to format the field as Rich Edit:

Once output escaping is disabled, you will see the HTML content correctly rendered:

Thanks,

Saiyue Yu

Hi everyone.  For those of you who have been waiting on Part 2 of this blog, I am truly sorry.  A valuable lesson that I've learned is - Don't break a blog article into multiple parts :)  With that said, let's get right to it.

For those of you who need a refresher on Part 1 (and who can blame you), please go here.

Today, I will walk through the 2 remaining things that I demo'd at the SharePoint Conference. 

1. Building an advanced view with an ASP.NET calendar control and a data view
2. Adding an MSN Weather RSS feed

I will be working off the same site and scenario that I used from Part 1, which is to build a SharePoint site to manage my golf course and golf shop business.

Demo #1 - Building an advanced view with an ASP.NET calendar control and a data view.

For the golf site that we are building, it would be great to create a view that allows us to easily check the scheduled tee times for our golf course based on a selected day.  We have a standard Calendar list that already tracks all the scheduled tee times.  (If you are following along for the first time, you can just add some sample items to a regular Calendar list)

Here are the steps:

1. Create a new blank page in SharePoint Designer
2. Attach default.master master page to the new page.
   1. Format->Master Page->Attach Master Page
   2. Select the default master page.
3. In design view, select the PlaceHolderMain content region.
4. Click on the OOUI button (arrow button that shows up when you select the region) and click "Create Custom Content"
5. Inside the content region, insert an ASP.NET calendar control
   1. Bring up the Toolbox task pane
   2. Drag and drop the "Calendar" control, from the ASP.NET Controls section, into the design surface.
6. Below the asp.net control, insert a data view of the Calendar list.
   1. Task Panes -> Data Source Library
   2. From the Data Source Library task pane, drop and drop the Calendar list into the page.
7. Click the OOUI button in the data view to bring up the Common Data View Tasks menu.
8. (optional) You can pick "Edit Columns" to modify the columns to display.  (In my demo, I picked the Title and the Start Time.)

So far, you have inserted an asp.net Calendar control and a data view showing list data from the Calendar list.  Next, we will create a parameter in the data view that will take in a value passed in by the ASP.NET Calendar control.

1. Click the OOUI button of the data view and select Parameters.
2. Click New Parameter.
3. Give the parameter a name (ie. CalControl)
4. Set Parameter Source to Control.
5. Set Control ID to the ID of the Calendar asp.net control.  By default, the ID is Calendar1. 
6. Hit OK

Now that you have the parameter set up, you want to add a filter to the data view in order to filter the scheduled tee times based on the date that a user selects from the ASP.NET Calendar control.

1. Click the OOUI button of the data view and select Filter
2. Check the Add XSLT Filtering checkbox and then click the Edit button.
3. This will bring up the XPath Expression Builder dialog.  Enter the following XPath expression:
   1. [ddwrt:FormatDate(string(@EventDate), 1033, 1) = ddwrt:FormatDate(string($CalControl), 1033, 1)]
4. Hit OK.

For basic filtering, you generally do not need to write a custom XPath expression.  The reason why we have to do it here is because the default date format returned by the ASP.Net Calendar control happens to be slightly different than the date format of the date/time field in the data view.  Therefore, basic filtering won't return the right results.  XPath expression gives you a more robust way to filter your data.  In the expression above, we first formatted both date/time values to be of the same format before we made the comparison.  If you are interested to learn more about filtering and formatting date values in a data view, please check out this earlier post.

Important note:  In this example, the XSL filtering will be done at the presentation layer and not the data source layer.  This can reduce performance of the data view, especially if there is large set of list data..  

After setting the filter, there is one more step remaining.  This is an advanced step that you can brag to your co-workers about :)  When setting the parameter in the data view for the ASP.NET Calendar control, you may notice that we never had specify a property for the control that we selected.  That's because we will automatically use the default property of whatever control you selected.  This works out well in most scenarios.  However, there are cases, like this one, where the default property of the control is actually not what we want to use.  If that's the case, you can make an advance modification in the code to specify exactly what property you want.  Let me show you how:

1. Switch to Code View
2. Do a search for 'CalControl' to locate the <ParameterBinding> tag for the CalControl parameter we set in the data view.
3. For the Location value in the <ParameterBinding> tag, make the following change:
   1. Location="Control(Calendar1, SelectedDate)"
   2. Note - SelectedDate is the property of the ASP.NET Calendar control for the date that a user selects.
4. Now save the page.
5. Browse to it.

Congratulations!  You have just created a rich view that leverages an ASP.NET control and the data view to help you better manage the scheduled tee times for your golf course.  The page should look something like this:

Demo #2 - Adding an MSN Weather RSS feed

For those of you who golf, you know how important of a role the weather plays into all this.  For the page we just built, we're going to take it one step further and add an MSN Weather RSS feed to display weather for the upcoming week.

Here are the steps:

1. Visit http://weather.msn.com/ on your favorite browser.
2. Enter the zip code (ie. 98121)
3. Click on the RSS feed button
4. Copy the URL of the RSS feed (ie. http://weather.msn.com/RSS.aspx?wealocations=wc:USWA0395&weadegreetype=F)
5. Open up a page in SharePoint Designer (we can just use the page that we worked on in the previous demo)
6. Bring up the Data Source Library (Task Panes -> Data Source Library)
7. Expand the Server-side Scripts section.
8. Click on Connect to a script or RSS Feed link.
9. Paste the URL above in the Enter URL to a server-side script text box.
10. Hit OK.

You have just created a data source to the MSN Weather RSS Feed.  You should see RSS.aspx on weather.msn.com in the Data Source Library task pane.

1. Drag and drop the new RSS Feed data source into the page
2. Click on the OOUI button of the newly inserted data view
3. Select Edit Columns.
4. Remove all columns except for description.
5. Back in design view, select one of the xsl values of the description field.
6. Click on the OOUI button of the xsl:value to bring up the Common xsl:value-of Tasks menu.
7. For the Format as: dropdown, change it from Text to Rich Text.
8. Hit Yes to confirm. (Because this data is coming from MSN, we can trust it)
9. Save and browse the page.

With just a few simple steps, you have now added an RSS Feed that displays the weather for the upcoming week in Seattle.  Your page should look something like this:

I hope you guys find this blog post useful.  Until next time!  Cheers.

Greg

Hi everyone, Allan Smith here. I’m a Software Development Engineer in Test on the SharePoint Designer Data team. I have a great example of using a server-side script data source to create Master-Detail views using the DataFormWebPart. My finished example is show in this screen shot:

I will use Flickr services as my data source in this example thus there are a few pre-requisites before we can get started. Flickr requires an API key in order to use their service but this is easy to setup by visiting their site at http://www.flickr.com/services/api/. I also recommend reading through their API methods to see what is available via this service.

For this example I have decided to use the flickr.photos.search and flickr.photos.getInfo methods. The Flickr site also has documentation on the different types of request/response formats they offer. We will be using the REST format. The documentation shows how your request string should be formatted which we will be using when we create our data source in SharePoint Designer.

The overall approach I use to create this example is as follows:

1. Create a Data Source that retrieves data from flickr.photos.search.

2. Build a view that is a grid 5x5. This is the master view.

3. Create a Data Source that retrieves data for a specific photo.

4. Build a view that displays the larger photo with details below it. This is the details view.

5. Add a textbox and button to search for a specific tag.

Create the Flickr Search Data Source:

1. Open the Data Source Library

(If the taskpane is not visible, go to the Task Pane menu and select Data Source Library)

2. Expand Server-side Scripts and click on the ‘Connect to a script or RSS Feed…’ link.

*Note: Server-side script is an odd name for historical reasons, but it is used when you specify a URL with parameters for a request and expect XML in the response.

3. A Data Source Properties window will open.

a. Select the General tab and name your Data Source. i.e. Flickr Search

b. Select the Source tab and enter the URL for the REST request with the parameters required by flickr.photos.search.

I am using the following URL where my default search text is ‘tree’:

http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=<your_API_Key>&text=tree

c. You will need to modify the method and api_key parameters so that they are not Runtime Parameters.

*Note: The runtime parameters option specifies whether a parameter can be modified at runtime or if it is static. Since we do not want to change the method or API key we will uncheck the Runtime Parameter box for these parameters.

Create the Master view

For my example I am using an html table to layout my views but you can use any method of your choosing.

1. Drag the Flickr Search Data Source onto the design surface.

2. Click the OOUI (On-object User Interface) toggle and select ‘Change Layout…’

3. Select the ‘two-column repeating form with border’ layout and click OK.

4. Select the data inside one of the grid cells and delete it. In this example we will not use the default fields given to us by the data source.

5. Insert an html image tag by going to the Insert menu, selecting HTML controls and clicking on Image.

You need to set the image ‘src’ attribute to the Flickr specific format here: URL’s documentation

I have formatted my URL to be:

http://farm{@farm}.static.flickr.com/{@server}/{@id}_{@secret}_s.jpg

*Note: The {@name} format represents an XML node in the returned data that gets inserted at runtime.

6. In the xsl below this img you will notice two lines that have “mod 2” in them. This is the code that specifies how many columns should be in your grid. I have changed this to be “mod 5” so we will have 5 columns in this example.

7. Select the OOUI again and set the paging to 25 so that we get a nice 5x5 grid.

*Note: You may want to remove the width attributes and styling for the view too so you get a better fitting grid for the images as shown below.

Create the Flickr getInfo Data Source:

Similar steps to creating the Flickr Search Data Source but with a few differences. The first and most obvious difference is that the request URL is different since we will be using the flickr.photos.getInfo method. This URL also requires different parameters and since these parameters will drive what data gets returned from Flickr, we need to set them with some default values so that SharePoint Designer knows what schema to expect.

To get these default values do the following:

1. Select the Search Flickr Data Source and click Show Data

2. From the Data Source Details task pane, copy down the id field value and the secret field value for one of the items.

Now you can create the data source

1. Create another Server-side script Data Source.

2. Select the Source tab and enter the URL for the REST request with the parameters required by flickr.photos.getInfo.

3. I am using the following URL

http://api.flickr.com/services/rest/?method=flickr.photos.getInfo&api_key=<your_API_Key>&secret=&photo_id=

4. Set the default values for secret and photo_id.

Create the Details View

1. Select the Flickr getInfo Data Source and click on Show Data

2. Select the fields that you want and click Insert Selected Field as… Single Item View

I selected title, description, realname, location, taken and url.

3. The next step is to create a webpart connection from the master view to the details view.

4. Click the first image in the master view and select the OOUI for the DataFormWebPart.

5. Select Web Part Connections…

6. Setup the web part connection with the following settings:

a. Send Row of Data To (Next>)

b. Connect to a Web Part on this Page (Next>)

c. Target Web Part – Flickr getInfo

Target action – Get Parameters From (Next>)

d. secret – secret

id – photo_id

farm – farm (You will have to create this new parameter)

server – server (You will have to create this new parameter

e. Create a hyperlink on - img

7. In the Details view add the following markup to add a larger version of the select image.

<tr>

<td colspan="2">

<img src="http://farm{$farm}.static.flickr.com/{$server}/{$photo_id}_{$secret}.jpg" />

</td>

</tr>

* Note this is similar to the URL above except for the ‘$’ character replacing the ‘@’ character. This is because the parameters will be passed in at runtime by the webpart connection and not retrieved from the datasource.

8. Select the URL field value and click on the OOUI for it. Select Format as Hyperlink.

Adding search capability

1. Above the views as another row and cell into the table.

2. Open the Web Parts Gallery

3. Drag over a Form Web Part into the new row and cell.

4. Right-click the web part and select ‘Web Part Connections…’

5. Create a web part connection from the form web part to the master view using the input as the text parameter

*Unfortunately the larger image doesn’t show up at design time because of the runtime parameters.

thanks,

Allan Smith