Microsoft SharePoint Designer Team Blog

SharePoint 2010 List View Blog Series: Part 1 – Introduction to the new List View

spdblog — Mon, 16 Nov 2009 23:46:00 GMT

Hello. This is Greg Chan, a Program Manager on the SharePoint team. I am excited to kick-off a new blog series that will cover a wide spectrum of topics related to the new List View in SharePoint 2010.

What is a List View again?

Put simply, a List View is a view for displaying SharePoint list data. The concept of List View has been around since SharePoint v2. While there are other technologies being used for visualizing list data in different scenarios (e.g. Content Query Web Part), List View remains the default component for displaying list data in SharePoint 2010.

List Views can be spotted everywhere in SharePoint. They are used to display information such as your announcements, tasks and calendar schedules.

Examples of list views:

What’s the big change with List Views in 2010?

In 2010, we are introducing a component called the XSLT List View Web Part (XLV) that serves as the new default technology for displaying list data. This honor used to belong to the List View Web Part (LVWP), which was the default from SharePoint v2 to 2007. (Note: LVWPs are still supported in SharePoint 2010, but just not as widely used as the new XLV.)

The new XLV brings a ton of improvements to the SharePoint platform. This blog series aim to cover most of these areas.

What are the key benefits to the new List Views (XLV)?

Replacing the default technology for List Views required fundamental changes to the SharePoint platform. So why did we do it? Let me call out the high level benefits of the XLV:

More Designer Friendly
- Rich customization support through SharePoint Designer while preserving browser UI experience
- Extensible and shareable custom styles
- Popular designer features such as Conditional Formatting.
More Developer Friendly
- Uses standards-based XSLT instead of CAML
- Better documentation
- Easily extensible
More End-User Friendly
- Enhanced user experience including Ribbon UI and new multi-selection model.
- Inline editing support
More Robust Ways to Access Data
- Display enterprise data through Business Connectivity Services (BCS)
- Cross-web list views displaying data from another web
- Display list data joined from different lists

What’s coming up in the blog series?

Many people from different teams in the SharePoint family contributed to the new List View in SharePoint 2010. In this blog series, you’ll get a chance to hear from some of those area experts covering key List View topics.

Here are the topics that will be covered:

Introduction to the new List View (you are reading it! :)
List View – New User Experience
List View Architecture
List View Customization
External Lists
Conditional Formatting
How to Share Your Custom List View Styles
How to Create Custom Fields for the new List View
Related Item View
How to Create Views Displaying Cross-Web and Joined List Data

The order in which these topics will be published may change. We may also add or modify topics on this list. If there is any areas regarding List Views that you’d like to learn about and isn’t on this list, feel free to suggest them here.

Thanks for reading. I hope everyone is excited about the new List Views. Stayed tuned for more!

Greg Chan

SharePoint Designer 2010 New Shell Tour

spdblog — Mon, 02 Nov 2009 22:20:00 GMT

Welcome to SharePoint Designer 2010! As Todd Haugen mentioned in his latest blog, we’ve got a number of wonderful features this release and we’re really excited to get them into your hands. This is a follow-up blog to dive into the new shell, or user interface, of SPD 2010. I think this is one of the greatest enhancements for the 2010 release. The new shell of SPD 2010 targets new and old users alike by highlighting SharePoint artifacts (not the folder structure they’re stored in), presenting key information you want to know about those artifacts, bubbling the tools and commands up to the Ribbon, and giving you intuitive navigation to explore, modify, and create rich and powerful SharePoint sites.

Opening a Site

Let’s start with what you will see first - opening a site. Figure 1 below shows the Sites Place in the Microsoft Office “Backstage” feature. Here in the Sites place, we have 4 areas: Open SharePoint Site, Recent Sites (my favorite), New SharePoint Site, and Site Templates. These categories are pretty self-explanatory. Notice two buttons that mention My Sites. Of course, you’ll need the Microsoft SharePoint Server feature to use these buttons. Something else that’s cool is the Site Templates category. This by default shows Blank, Blog, and Team Site. But, clicking More Templates you can browse for a server with more templates, then mark favorites that will show up by default next time you open SPD. As I mentioned before, my favorite section is the Recent Sites. This list shows the recent sites you’ve visited and with one click the site opens – a real time saver.

The first time you open SPD, you’ll need to click the “Open Site” button. This brings up a dialog similar to 2007. Type your SharePoint 2010 site address where it says “Site name:” then click open. You can browse for any of its subsites, or click open again to open the site.

Figure 1. The first thing seen on booting SharePoint Designer 2010 is the Sites Place in the Backstage. From here you can open a site or create a new one.

Galleries, Settings, and Editors

Ta dah! What you see next is very different from SPD 2007 (figures 2 and 3 below show 2010 and 2007 respectfully).

Figure 2. After opening a site, you're launched Onstage to the new user interface of SharePoint Designer 2010. We have incorporated the ribbon, a navigation pane focusing on SharePoint artifacts, a breadcrumb with helpful navigation, and the concept of Gallery Pages, Settings Pages, and Editors. This image is the Site Settings Page – showing key site information, links to quick customizations, general settings, site permissions, and subsites. The ribbon has commands to create artifacts and manage the site as a whole.

Figure 3. Opening SharePoint Designer 2007 launched to a new and blank html page. The core of the user interface was based around the page editor and file structure.

The first thing you may notice is the Ribbon. Also, there’s a lot less white space (we don’t open a blank .html page for you). Instead there’s a spread of information contained in labeled sections. Last but not least, the Navigation Pane on the left. I’ll talk a bit more of the navigation (nav) pane soon, but one thing to note is what it contains – SharePoint artifacts. When you’re looking for something, you don’t have to remember where it’s stored.

Settings Pages

Let’s dive into the assortment of information on the opening page (Figure 2). This is what we call a “Settings Page” which surfaces relevant information and related artifacts for the specific thing you’re looking at. The first page shown upon opening a site is the site settings page, which displays key site information (name, description, URL, SharePoint version number, etc.), permissions for the site, quick customization links, general settings, and a list of subsites below the current site. Settings pages all have a similar layout, but might contain different packets of information. For example, the list settings page shown in Todd’s blog displays key list information, customization links, general list settings, views, forms, custom actions, and workflows associated to the list. These settings pages serve as great launching places for building or modifying the artifacts. Modifying a list may require adjusting settings, permissions, creating a new view or form, or even modifying list schema. All of these actions are reachable in at most one click from list settings page.

Gallery Pages

Gallery pages show a list of artifacts. These are usually reached by clicking an item in the nav pane. Clicking Lists and Libraries will open the Lists and Libraries Gallery shown in Figure 4.

Figure 4. The list and libraries gallery shows all of the lists and document libraries in the site.

Gallery pages are helpful for getting a big-picture look at contents of the site: how many workflows there are, or what types of list you have, etc. The ribbon is alive here, and you can perform actions like creation, or editing, and there’s also some links to the browser (I use the F12 shortcut to preview in browser all the time). Galleries can also be viewed as a “mini-gallery” below the artifacts in the nav pane. Use the pin to the right of the artifacts to pin open the gallery (see Figure 5). One cool shortcut I’ll mention here is that most galleries have different behaviors for single and double clicking. Single clicking the name of an artifact will open its settings page. Double clicking the item will open its editor.

Figure 5. Mini-galleries can be pinned open from the navigation pane. Here, the data source gallery is showing list data.

Editors

Some artifacts in SPD have a separate view for editing: Lists/Libraries, Content Types, External Content Types, Pages, and Workflows. These editors are all worthy of blogs themselves. The page editor is very similar to the whole of SPD 2007. It incorporates the ribbon, and there are a couple great new features (like Skewer Click) that are worth checking out. The workflow editor is now full screen, and packed with new and wonderful features (definitely look for a blog on this coming soon). The schema editors for lists and content types are fast and very helpful for rapid prototyping. And lastly, the external content type editor is a powerful tool to pull in external data systems into SharePoint (for sure going to be a blog or two on this – way cool!).

Breadcrumb, Tabs, and Navigation

The navigation story is one of the most helpful parts of the new shell. It’s a suite of features that help users find what they want quickly and easily. Much of the user interface navigation can be compared to Windows Explorer. There is a breadcrumb with back and forward buttons (I use my extra mouse buttons all of the time for these back and forward clicks). The breadcrumb is great for drilling down or stepping upward. Figure 6 below shows drilling down options from the Calendar list settings page.

Figure 6. The breadcrumb allows for quick drilling down or stepping upward. The Back and Forward buttons act just like a web browser.

Each tab will also keep a memory of its history, so you can bounce backward in time (Figure 7).

Figure 7. The history button in the breadcrumb is often very handy. Each tab remembers its history, and like a web browser you sometimes want to jump backward multiple steps.

Of course, the navigation pane already mentioned is a great starting point. Clicking an item in the nav pane will usually open a new tab to display the gallery page for that item. If your current tab is a gallery already, it will navigate within the tab. The last two sentences may be a little tricky to understand without trying it yourself, but we hope it just feels right when you’re doing it, and it’s helpful for managing the number of tabs you have open. One really cool feature is the ability to drag tabs in the order that you like (similar to Internet Explorer). This is really helpful for me when I’m working with a page and a couple .css files. If I opened them in a different order that I want to organize them, “click-swipe” and I’m organized. You can also open new tabs by clicking the mini-tab on the right of the last tab.

Odds and Ends

Here’s just a couple blurbs on other things I thought were worth mentioning.

Log In As…

In 2007 it was quite tricky to log into SPD as a different user profile (someone explained once how to do it, but I was lost after step 2). In 2010 however, clicking the little figure in the lower left allows you to sign out and back in with a different user profile. This is also a great way for site owners to see how our permission controls affect users of differing permissions. Look for a blog soon on the “Giving IT Control” feature that allows administrators the ability to control what their users can do with SPD.

Figure 8. The Log In As feature is helpful for users or teams multiple accounts.

Ribbon and QAT Customization

Along with Add-ins, you can add commands to the QAT (Quick Access Toolbar) and Ribbon with the new extensibility available (see Figure 9).

Figure 9. The Quick Access Toolbar and Ribbon are easily customized to contain what you want. Here I’ve added some commands to the QAT and I’ve created my own ribbon tab with my favorite buttons.

A Few Limitations to Call Out

Early on in development we made a tough choice. Not supporting backwards compatibility with SharePoint v3 and earlier. This means that SPD 2010 will only work with SharePoint 2010. Although this was hard, it allowed us to build better, farther and test deeper. I almost think of SPD 2010 as a new product, a new toolset for SharePoint 2010. This of course means that we are supporting side-by-side installation of SPD 2007 and 2010. There is one important thing to keep in mind when setting up side-by-side. Stick to the same flavor of clients (x64 and x86). SPD 2007 only came in x86, so only use x86 SPD 2010 when installing side-by-side. This is for all Microsoft Office apps as well. So don’t install 64-bit SPD with 32-bit Office.

As we shifted to being a powerful and usable toolset for SharePoint 2010, we securely attached to SharePoint. In other words, SPD focused at being only a SharePoint tool. Unfortunate for some, this means that you won’t be able to use its page editor without also having SharePoint. The page editor is only available when a SharePoint site is open. If you try to open a page in SPD without opening a site first, you will get the following error message. Microsoft Expression Web is our recommended tool for stand alone page editing.

Figure 10. SharePoint Designer 2010 is tied to SharePoint, and cannot be used as an independent page editor. Without a site open, you will get this error when opening a page or file with SPD.

Wrap Up

Thanks so much for reading! SharePoint Designer 2010 is an easy-to-use, robust, helpful, and a slick-looking tool. The full spectrum of users, from Information Workers to Power Developers, will see value and usability in SharePoint Designer 2010. Keep your eyes out for more blogs on other great features and our Beta2 release. We’re so excited for SharePoint 2010 and hope you are too!

Putting the SharePoint in SharePoint Designer

spdblog — Tue, 20 Oct 2009 01:36:00 GMT

For those of you who have been with us for the long haul, you know SharePoint Designer (SPD) evolved from the FrontPage product. The result of this lineage was SPD 2007 largely focused on web page editing and added some SharePoint capabilities. In SPD 2010, we increased our investment in SharePoint capabilities and focused on exposing the power of SharePoint to both power users and developers alike. SharePoint has always been about the democratization of web development - think of SPD 2010 as furthering that goal.

Figure 1. SPD's new shell focuses more on SharePoint objects and less on the file structure and page editor. The UI is now much more intuitive and helpful with the Ribbon and navigation pane.

When you think about democratization, a few words come to mind: awareness, access, utility. If you're an IT shop, some other words might come to mind too: safe, supported, compliant, and dare I say governed? When we started our mission, we took these words to heart. We were more successful addressing some goals than others, but let’s be clear, we understand that it's not a good idea to simply empower every Tom, Dick, and Jane with a simple, powerful application building tool and just hope IT can deal with the explosion of applications.

So to that end we will start with the IT side of the equation:

Safe: Multi-tenancy is one of the huge strengths of SharePoint, but this often limits what users can do with the system. The shared nature of the system means users cannot add powerful server side code to the system. In this release we provide User Solutions, a server sandbox enabling users to upload their own code or code from a third party to complete their scenarios where that code runs in an isolated process. Even better, IT has control over the throttling and contents of the sandbox so shops can tune it for their level of comfort.
Supported: Historically when you put SPD in the hands of a user, despite best intentions, they broke things. And this resulted in support calls, lots of them. In this release SPD is Safe by Default. Users cannot simply edit the master page or delete a content place holder and bring down an entire site collection! This is a powerful IT feature that will require its own blog to explain in detail, but the gist is users cannot just open a site and break it before they even know what they’ve changed.
Compliant: Because we have locked down the capabilities in SPD, IT shops can now control which templates, master pages, and styles can be used in their orgs. This makes it easy to ensure sites comply with corporate policy.
Governed: In this release we did not only improve the supportability of SPD, we gave IT simple, granular control over who can use SPD on which areas of their farm.

Now that you know IT is going to bless the use of SPD, let’s dig into the end user aspects of the democratization of web development - awareness, access, and utility.

Awareness: We can make all the improvements in the world on this tool and it will be largely irrelevant if users are not aware the tool exists. To help address this issue and drive efficiencies we now directly link the SharePoint browser interface with SPD. Through these links we have significantly reduced the complexity of using SPD to edit specific, targeted aspects of SharePoint sites. This means users simply click a button in the browser and SPD is opened directly to the right spot. A future blog will cover all the links in detail but here is an example (Figure 2), cool huh! Yes, these links only show up if the user has permissions to SPD - remember what I said in the governance section?

Figure 2. Contextual links appear in the browser UI that link directly to the SPD design surface. For example, clicking the Modify in SharePoint Designer link will open SPD to the current site, then open the specific list view in the page editor for editing. Advanced customizations such as conditional formatting are now much easier to add.

Access: Many of you may not even know what SPD is or that it even existed, much less that this tool will help your organization get the most out of its SharePoint installation. There were two primary reasons for this lack of awareness, 1: due to its price tag many organizations opted not to buy only limited copies of SPD, and 2: because of its power, many IT organizations restricted the use of SPD on the network. This release our team worked hard to address these issues that blocked user access to SPD.

1. FREE! That is right, you heard me, FREE! SPD is now available as a free download.

2. Safe by Default, with this release it is very hard for users to shoot themselves in the foot. Look for a future blog on this - but suffice to say, it takes explicit permissions to unghost a page!

Figure 3. The new shell is highlighted by Settings Pages that quickly display relevant information and related artifacts to your SharePoint objects. This list settings page for example, displays key list information, general settings, list views, forms, custom actions, and workflows associated to the list. Using the ribbon it is easy to edit or add to this list.

In addition to the UI there are a number of other features we have added to make the tool more useful for IWs:

Workflows have been dramatically improved with a new editor (Figure 4), reusable workflows, and even more powerful workflows that come out of the box. Look for several workflow blogs to come out soon.

Figure 4. Workflows are now easier and more flexible to create in SPD. The full screen designer incorporates the ribbon and other intuitive UI.

XSLT List Views are also a big investment for us. XSLT list views are now the default view for lists which means developers only have to learn one list technology! This standardization also let us deliver some great features such as Push Button Styles that enable styling and conditional formatting with the push of a button. Of course we will have a blog or two on this topic too.

I hope you enjoyed reading about the breadth of features coming from SPD this release and we would love to have you back soon to read about these and other features in detail. For now let me leave you with a parting thought: in this release we invested heavily in IWs to complement the functionality offered to developers and designers. Additionally you will see amazing stuff from VS and Expressions in forthcoming releases integrating with SPD and the best SharePoint has to offer. Of course, look for blogs on these topics in the coming months too.

Signing off for now –
Todd Haugen (SPD GPM)

Service Pack 2 prevents an on-change workflow from starting itself

spdblog — Mon, 13 Jul 2009 21:38:09 GMT

Hello all, Stephen here again — I’m a writer for SharePoint Designer. I’d like to tell you about a fix that was included in Service Pack 2 for Office SharePoint Server 2007 and Windows SharePoint Services 3.0. This fix affects workflows designed in SharePoint Designer 2007. Then I’ll show you how to intentionally create a workflow loop by using two workflows instead of one.

Before Service Pack 2, it was too easy to inadvertently design a workflow that triggered itself and created an infinite loop. For example, consider this scenario:

1) A workflow starts when an item is changed.

2) The workflow updates (or changes) the current item (e.g. by using the Set Field in Current Item action).

3) Because the workflow changes the item, it triggers itself.

So if you had an on-change workflow that sends you an e-mail and then updates the current item, you could quickly receive several hundred e-mails in your Inbox.

After you install Service Pack 2 on your server, it is no longer possible for a workflow that starts when an item is changed to trigger itself by changing/updating the current item. This infinite-looping scenario is not possible:

Many people, however, have designed workflows that actually leverage infinite looping. For example, you could design an on-change workflow that loops endlessly on a task item and that sends a daily reminder until that task is marked complete. The workflow triggers itself by updating a Counter column that was added to the list just for this purpose. And the workflow has a rule that stops or “short circuits” the workflow if some condition is satisfied — in this case, the workflow stops without changing the current item if the task Status = Completed. After SP2, this workflow will in effect be broken because it cannot trigger itself.

SP2 does not block infinite loops, which can be useful, but to re-create what worked before you must design two (or more) on-change workflows that trigger each other. Two on-change workflows that trigger each other by updating/changing the current item is a “co-recursion” scenario:

In addition, it is very common to implement a state-based workflow by using several shorter workflows that trigger each other. For example, you might have a list with a Status field and several on-change workflows attached to that list. All of those workflows include a step at the end that updates the Status field. So one workflow triggers several others by updating the Status, and then those workflows look at the value in the Status field to determine whether they should continue running or stop. This state-based workflow is also a “co-recursion” scenario because one workflow starts many other on-change workflows by changing/updating the current item. Service Pack 2 does not block this type of state-based workflow that relies on co-recursion.

Recap

· Before SP2, a single on-change workflow could enter an infinite loop by updating the current item, thus triggering itself.

· After SP2, an on-change workflow can trigger any other on-change workflows by updating the current item, but an on-change workflow cannot trigger itself. So co-recursion scenarios -- including any scenario that implements a state-based workflow by using many smaller on-change workflows -- are not blocked.

· As a reminder, it has never been possible to create an infinite loop by having an on-create workflow create an item in the current list. Every workflow has a property that contains the “workflows I cannot start” — this property is used to prevent looping for workflows that start when an item is created.

· As a further reminder, all of the previous scenarios involve only workflows attached to a single list or library. Infinite looping in cross-list scenarios has never been blocked for either on-change or on-create workflows.

Creating loops before Service Pack 2

This section presents an example of how a single on-change workflow could leverage infinite looping before SP2. After SP2, this workflow will not trigger itself, so the next section presents an example of how to create a loop by using two separate workflows.

Assume you have a task list named Team Tasks, and you want to design a workflow that will send a reminder every day until the task is marked complete.

First, add a column named Counter to the list with a default value of 0.

You need to hide the Counter columns from the list forms (New Item, Edit Item) so that only the workflow can access/update it. Fist, on the list settings page, click Advanced Settings, and then allow the management of content types.

On the list settings page, click each content type, and on the next page click the Counter column. Make the Counter column hidden. Do this for every content type in the list.

After creating and hiding the Counter column so that it does not appear in forms, you’re ready to design the workflow.

The Daily Reminder workflow should start whenever an item is created or changed.

The first step checks for two things: (1) If the task has already been marked complete, the workflow stops. This rule “short-circuits” the loop whenever the task is finally marked complete. (2) If the task is not completed, the workflow checks to see if the due date is in the future (greater than today). If this is true, the workflow pauses until the due date, because you don’t want to send reminders until the due date has been reached.

The second steps again checks whether the task is completed (in case the workflow paused until a due date on the previous step, and the task was completed in the interim). If the task is still not complete, the workflow pauses for one day.

The third step again checks to see if the task was completed while the workflow was paused; if true, the workflow stops.

If the task has not been completed, the workflow (1) sends the e-mail reminder; (2) set the CurrentCount variable by doing a lookup to the Current Item/Counter field; (3) adds 1 to CurrentCount and stores this value in a NewCount variable; and (4) sets the Counter column to the value stored in the NewCount variable.

Basically, this step increments the Counter column by 1 each time the workflow runs, so you can look at the Counter column to see how many reminders have been sent. And most importantly, the “Set Field in Current Item” action at the end of this step is what “changes” the current item, thus causing the workflow to trigger itself and create the loop.

Creating loops after Service Pack 2

After SP2, you can still achieve this looping effect, but it requires designing two workflows that trigger each other (co-recursion) instead of a single workflow that triggers itself.

Here you’ll use a (1) Counter workflow that increments the count and a (2) Worker workflow that actually sends the reminder mail.

1st workflow — the Counter workflow

As above, you need to create a Counter column in the list with a default value of 0, allow the management of content types, and make this field hidden for every content type in the list.

This two-workflow design requires a second column, SendMail, which will act as a flag for the Worker workflow. The default value must be No – otherwise, any change to a task item would cause the reminder mail to be sent.

The Counter workflow will start when an item is created or changed.

The first step checks the task status – if the task is complete, the Counter workflow stops.

If the task due date is in the future (greater than today), the second step pauses until the due date, because you don’t want to send reminders until after the task is due.

The third step again checks for task completion, in case the task was completed while the workflow was paused on the previous step. If the task is still not complete, the workflow pauses for one day.

The final step checks the status again to see if the task was completed during the previous day-long pause. If not, the workflow updates the current item by (1) incrementing the value of the Counter column by one and (2) setting the SendMail flag to Yes (the default value is No).

2nd workflow — the Worker workflow

The Counter workflow above ends by updating (changing) the current item. These updates trigger the Worker workflow, which is set to start when an item is changed.

The Worker workflow simply checks to see if the SendMail flag is set to Yes; if true, the workflow sends the reminder message and sets the flag back to No.

Setting the SendMail flag to No is the change that triggers the Counter workflow above. The Counter and Worker workflows will trigger each other, sending daily reminders until the task is marked complete.

Alternatively, instead of an infinite loop, you can have the Worker workflow escalate the task notification when the Counter column reaches a certain value — say 5 reminders. The following step executes different branches depending on the reminder count. When the count reaches 5, the workflow sends a message to a manager, whose e-mail address you can either “hard-code” into the Send an Email action or retrieve from a list by using a workflow lookup.

You could also have the Worker workflow reassign the task to a different individual or group after a certain number of reminders have been sent. For this step, the workflow reassigns the task to a SharePoint group comprised of team members who are responsible for following up on such escalated tasks.

If you want to end the loop when the count reaches a certain number, also make sure to add a branch to the first step of the Counter workflow – not the Worker workflow. This branch stops the loop when the Counter column reaches 6.

I hope you find this useful.

—Stephen

Download SPD for FREE today!!

spdblog — Thu, 02 Apr 2009 22:29:00 GMT

Today we are excited to share with you some news about SharePoint Designer 2007. Starting now (April 2, 2009), SharePoint Designer 2007 will be available as a free download! We want more of you customizing SharePoint and feel that this a good way to put the tool in the hands of more people. You can find a lot more information in our site including:

a) Letter to our Customers

b) Frequently Asked Questions

c) Free Download

Also, make sure to watch this video where Tom Rizzo and J.R. Arredondo discuss these changes and provide some insights into what is coming in the future (pick the appropriate version for your bandwidth).

· Small size video (6MB)

· Medium size video (17 MB)

· Large size video (83 MB)

Regards,

The SharePoint Designer Team

Visio diagram and site template from Office Online workflow videos

spdblog — Tue, 27 Jan 2009 21:44:00 GMT

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.

Creating RESTful Mashups using SPD 2007 (Part 1)

spdblog — Sat, 06 Dec 2008 03:30:00 GMT

Hi! J.R. and Kolby here to share an exciting example of the mashup capabilities of SharePoint. This is the first of two blog entries discussing how to use SharePoint Designer 2007 to create mashups.

The word "mashup" has become one of the most repeated buzzwords in the industry over the past few years. Promising ease of data integration and rapid development, mashups have become an integral part of the Web 2.0 lexicon. Many people are now familiar with the stereotypical mashup example of some data rendered on a geographical map.

Most initial applications of mashup technologies happened in the consumer space. For example, in 2007 Microsoft set out to create a tool integrated with a social network targeting the typical MySpace user. Popfly™ was the result of those efforts and has a very large user base already. It was even voted as one of PC World’s Top 25 Most Innovative Products for 2007.

Information Technology (IT) organizations have now begun to consider the applicability of mashup technologies to business use, attracted not only by the potential benefits derived from giving end users the ability to get things done on their own, but also to maximize the return on investment on SOA and data integration initiatives.

This article focuses on building mashups using SharePoint. Specifically, we will show you how to connect to external REST services using SharePoint Designer to bring data into a page in the form of web parts, and connect these web parts to create the mashup. Finally, we will show you how to render data on a geographical map using XSLT.

Scenario

The business scenario we will implement is about recruiting. Imagine a recruiter who has to stay in touch with a group of potential recruits and provide each one of them with personalized conversations as part of the recruiting process. This scenario is applicable to HR recruiting, college and professional sports recruiting, etc. In our example, the recruiter would like a way to have some insight as to what is going on in the recruit’s life before placing a phone call to follow up. In order to accomplish this, the recruiter would like to create a mashup using Twitter, MSN Weather, and the recruit’s personal information stored in a SharePoint list.

End Result

Our solution will consist of two pages. The main page (default.aspx, shown in Figure 1) will show the recruits information in a list in addition to a geographical map that displays their location. When the user clicks on one of the pins or markers on the map, a bubble pops up showing basic information about the recruit. This bubble also includes a link to our second page (mashing.aspx, shown in Figure 2). This page shows the recruit’s information, his or her Twitter image and latest status, and local weather information from MSN Weather.

Figure 1. Final result of the default.aspx page.

Figure 2. Final result of the mashing.aspx page.

Figure 3 below shows the high level conceptual flow of our application. When a user clicks on the recruit’s name on default.aspx, they navigate to mashing.aspx. Mashing.aspx receives a parameter in the query string called “name” to determine which recruit to render. You can choose another parameter such as email address if you like. From a user perspective, it is easy to use mashing.aspx by knowing only the name of the recruit. It also makes it easy for us to test our page. We will discuss default.aspx in Part 2 of this blog entry. Today, we will focus on the creation of mashing.aspx, the page that mashes Twitter and MSN Weather data with the SharePoint list.

Figure 3. Conceptual flow between two pages.

Building the mashing.aspx Page

As we see in Figure 3, mashing.aspx has essentially three web parts: the individual’s information, the Twitter web part, and the MSN Weather web part. The following is a concise outline of how mashing.aspx is created:

Create a blank page in the desired location
Add the three web parts with the desired information from each data source
Connect the different web parts
Format as desired

Step 1. Create a page in the desired location

We will assume the SharePoint contact list is already created, and it is named “Recruits” (see Figure 4 below). This SharePoint list should contain basic recruit contact information. The two key pieces of information we want in this list are Email Address (to connect to Twitter) and Zip Code (to connect to MSN Weather).

Figure 4. The Recruits SharePoint list with contact information.

The first step is to create an .aspx page. Open SharePoint Designer to the site where you want to put the mashup, and click File > New > ASPX. This is shown in Figure 5:

Figure 5. Create a new .aspx page and save it with the desired name.

Save the page with the desired name and location (Ctrl+S or click the Save button). We are going to call the page mashing.aspx and locate it in the global site folder.

Hint: One helpful thing to do immediately after creating a new page, is to press enter a few times. This enlarges the form area, making it easier navigate the page editor. After entering data, it is easier to click back into the form to add more data separated by a space or two. We find this super helpful when trying to format the page later.

Figure 6. The saved page appears in the Folder List on the left.

Step 2. Add the desired information

After creating a new page, the next step is to place the desired information on the page. First, we will add contact information from the Recruits list onto the page. We’ll use a single item view. If the Data Source Library task pane is not already open, click Task Panes in the toolbar to open it. Display the available list information by clicking into the Data Source Library > Recruits > Show Data (see Figure 7).

Figure 7. To insert the web part containing the recruit's information, click on the Recruits list in the Data Source

Use Ctrl-click to highlight all of the desired fields that you want to display about the recruit (we will select Full Name, EmailAddress, Phone, Address, City, State, ZIP, and Country). Then click Insert Selected Fields as… > Single Item View (see Figure 8 and Figure 9).

Figure 8. Using Ctrl+click, choose the list fields that you want to display on the page. Then enter them as a Single Item View.

Figure 9. The list data after being placed on the page.

twitter.com

The next step will be to configure Server-side Scripts to pull in external data. We are going to use data from twitter.com and MSN Weather, both of which are RESTful services. Again, using the Data Source Library, click Server-side Scripts > Connect to a script or RSS Feed… Use the dialog to name the source (General tab) and enter the URL (Source tab). For twitter.com, we use the following URL service.

http://www.twitter.com/users/show.xml?email=youremail@domain.com

This URL passes one parameter, an email address. If the email address is associated with a twitter.com account, the service will pass back all of the account information including their current status and the URL for their profile image. Figures 10-12 show these steps…

Figure 10. Click "Connect to a script or RSS Feed..." to add an external REST data source.

Figure 11. Configure the source by following the dialog instructions. Here, the name of the source is added.

Figure 12. The URL is entered for the source. Here, the specific URL for the Twitter service is added.

After the service is configured, we can add the data to the page similar to the contact information. Click twitter.com > Show Data. Ctrl-click the status text and the profile_image_url >Insert Selected Fields as… > Single Item View (see Figure 13).

Figure 13. Pick the new Twitter data source, show its data, select the desired fields, and insert them as a Single Item View.

To show the profile picture as an image and not a URL you need to set the Format as Picture. This can be done via the On-Object User Interface (OOUI) dropdown menu. When you have focus on something, like a web part, you often see a ‘>’ or chevron on the top right of the object. Clicking the chevron opens a dropdown menu (the OOUI). To set change the picture to an image click the URL text > OOUI > Format as: > Picture. The image should then show (see Figures 14 and 15).

Figure 14. The external Twitter data has been added to the page. To show a picture instead of a URL, adjust its format.

Figure 15. The Twitter profile picture now appears as an image.

MSN Weather

Configuring and the MSN Weather data source follows the same procedures as the twitter example. The URL used to create the data connection is as follows.

http://weather.msn.com/RSS.aspx?wealocations=98052&weadegreetype=F

This URL passes two parameters: the location in Zip code form and the units for the temperature (F = Fahrenheit and C = Celsius). Use a valid Zip Code to test the data connection. In our case, we will use the zip code 98052, Redmond, WA.

Figure 16. Insert the MSN Weather data as a Multiple Item View. This will show both the current weather and the forecast.

To display the weather feed, we will insert the data as a Multiple Item View. This will show us both the Current conditions and the Forecast. In the Data Source Library, click on the weather source > Show Data and then choose the item/description field > Insert Selected Fields as… > Multiple Item View (see Figure 16). Again, the “Format as:” selection will need to be adjusted. Set the format to Rich Text (using the OOUI).

Figure 17. Again, the inserted data needs to be formatted differently to appear correctly. Choosing Rich Text format will show the weather feed correctly.

We now have all of the data sources configured and displayed in three different Data Form Web Parts (DFWP) on our .aspx page (see Figure 18 below).

Figure 18. The page now contains all of the data, both external and internal.

Step 3. Connect the different parts of information

The goal for our mashup is to show data unique to each recruit (and be able to select which recruit’s data to display). Right now, we have static data for one recruit, and external data from whatever example we typed into the server-side script URLs upon configuration. To solve our problem, we will use a filter with a query string to pick an individual recruit along with Web Part Connections to link the three Web Parts.

Start with the contact list data from Recruits. Click on the list Web Part > OOUI > Filter:. A dialog titled “Filter Criteria” appears (Figure 19). Follow these steps:

Click “Click here to add a new clause”
Field name = Full Name
Comparison = Equals
Value: choose Create a new parameter (opens another dialog called “Data View Parameters”)
Parameter Source = Query String
Query String Variable = recruit
Default Value: pick a name within the Recruits list (if you don’t pick one, the web part will be blank and difficult to work with)
Click OK
Click OK

Figure 19. Filter the Recruits list web part to show the data for the recruit passed in the URL query string.

Figure 20. Create the query string parameter to use in the filter.

At this point, we could preview the page and see contact information, along with the twitter.com and MSN Weather data for the examples that were used to configure them. Changing the URL query parameter to different names would show us the unique contact info for those names (the URL is the page URL with the following attached to the end: “?recruit = [name]”). But, even though the recruit data changes, the twitter and weather info would not. Next, we need to connect the recruit with their twitter info and the weather for their location.

To connect the twitter source to the email address column of the Recruit list, we will use Web Part Connections. Click on the twitter Web Part > OOUI > Web Part Connections… (Figure 21). A dialog with title “Web Part Connections Wizard” will appear. Follow these steps (Figure 22).

Choose the action… = Get Parameters From
Click Next
Click Next (for Connect to a Web Part on this page)
Target Web Part = Recruits
Target action = Send Row of Data To
Under “Columns in Recruits” click <none> on the same row as email under “Inputs to Twitter” and select E-mail Address.
Click Next
Click Next
Click Finish

Figure 21. Use Web Part Connections to send the recruit's email address to Twitter.

Figure 22. Follow the wizard, connecting the REST sources to the Recruits list.

The Twitter Web Part is now linked with the Recruits Web Part. A box should appear at the top of the page labeled “SPWebPartManager – WebPartManager”.

The MSN Weather Web Part can be connected in the same way. Click on the MSN Weather Web Part > OOUI > Web Part Connections… to open the Web Part Connections Wizard.

Choose the action… = Get Parameters From
Click Next
Click Next (for Connect to a Web Part on this page)
Target Web Part = Recruits
Target action = Send Row of Data To
Under “Columns in Recruits” click <none> on the same row as wealocations and select ZIP/Postal Code.
Click Next
Click Next
Click Finish

Ta Da! All of the Web Parts are now connected to each other. When the page URL is submitted, the server draws the Recruit name from the URL, displays that recruit’s information, sends the recruit’s email address to Twitter and their zip code to MSN Weather, receives the data from both services, and displays all of the unique information on the page! Figure 23 displays what the page looks like in the browser.

Figure 23. With all of the data sources inserted and connected, this is what the page looks like before formatting. Changing the name in the query string of the URL displays unique information for that recruit.

Step 4. Format as desired

The page can now be formatted to any degree, making the page easy to use and look good. The first thing that we would do would be to attach a Master page to help the page fit in with the rest of the site. This can be done easily by clicking Format > Masterpage > Attach Masterpage… > OK. Next, text can be formatted, colored, or moved around. Figure 24 shows an example of what the final result could look like.

Figure 24. The final mashing.aspx page with a master page and some formatting.

Hope you enjoyed it! Coming up soon, Part 2: the map...

Locking Down SharePoint Designer

spdblog — Tue, 25 Nov 2008 22:18:00 GMT

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.

SCOPE	OPTION	PERMISSIONS REQUIRED TO ENABLE OR DISABLE
At the server level per site definition	ONET.XML — Prevent all users from opening all sites created from a specific site definition (such as all team sites or all publishing sites) by modifying ONET.XML for that site definition.	Server administrator — You must have an administrator account on the server to modify this file.
At the Web application level for all users	Permissions in Central Administration — Prevent all users from opening or editing all sites in a Web application by removing the permissions in Central Administration.	Site Collection Administrator — You must be a Site Collection Administrator to add or remove permissions in Central Administration.
At the Web application level per user or group	Policy in Central Administration — Prevent specific users and groups from opening or editing all sites in a Web application by removing the permissions in Central Administration.	Site Collection Administrator — You must be a Site Collection Administrator to manage permission policies in Central Administration.
At the site level per user or group	Site permissions — Prevent specific users and groups from opening or editing sites at the site level by removing the permissions from their permission level. Site permissions cannot override permission settings in Central Administration.	Site owner — You must have the Manage Permissions permission to configure site permissions. In SharePoint Server 2007, by default only the Full Control and Manage Hierarchy permission levels include this permission.
At the site level per user or group (not a security feature)	Contributor Settings — Guide trusted users toward performing the right tasks in the right place by disabling features and UI in SharePoint Designer 2007. Contributor Settings cannot override permission settings at the site level or in Central Administration.	Site owner — You must have the Manage Permissions permission to turn Contributor Settings on or off. In SharePoint Server 2007, by default only the Full Control and Manage Hierarchy permission levels include this permission.
Per computer or per user	Group Policy — Use policy settings to disable menu commands and their corresponding toolbar buttons in the UI of Office programs, including SharePoint Designer. You can also disable keyboard shortcuts. Settings can be applied to a specific computer or user.	Windows administrator — You must be a member of the Domain Administrators security group, the Enterprise Administrators security group, or the Group Policy Creator Owners security group.

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.

PERMISSION	DESCRIPTION	EFFECT ON EDITING WITH SHAREPOINT DESIGNER
Add and Customize Pages	Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services-compatible editor.	Without this permission, you cannot edit files at the root of the site (such as default.aspx in a team site) or files that reside in folders outside of lists and libraries.
Browse Directories	Enumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces.	Without this permission, you cannot open a site in SharePoint Designer.
Manage Lists	Create and delete lists, add or remove columns in a list, and add or remove public views of a list.	Without this permission, you cannot delete libraries, lists, or list forms or views (such as AllItems.aspx) in SharePoint Designer. However, if a list does not inherit permissions from the site, the list permissions apply to that specific list. Note that by default, the Workflows document library does not inherit permissions from the site; you must manage these permissions separately.

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.

FOLDER	SITE NAME
BDR	Document Center
BLANKINTERNET	Publishing Site with Workflow
BLANKINTERNETCONTAINER	Publishing Portal
Blog	Blog
CENTRALADMIN	Central Administration
MPS	Includes the site definition configurations for: Basic Meeting Workspace Blank Meeting Workspace Decision Meeting Workspace Social Meeting Workspace Multipage Meeting Workspace
offile	Records Center
OSRV	Shared Services Administration
PROFILES	Profiles
PUBLISHING	Publishing Site
SPS	SharePoint Portal Server Site (legacy - this template is obsolete)
SPSCOMMU	Community area template (legacy - this template is obsolete)
SPSMSITE	Personalization Site
SPSMSITEHOST	My Site Host
SPSNEWS	News Site (legacy - this template is obsolete)
SPSNHOME	News Site
SPSPERS	SharePoint Portal Server Personal Space
SPSPORTAL	Collaboration Portal
SPSREPORTCENTER	Report Center
SPSSITES	Site Directory
SPSTOC	Contents area template (legacy - this template is obsolete)
SPSTOPIC	Topic area template (legacy - this template is obsolete)
SRCHCEN	Search Center with Tabs
SRCHENTERLITE	Search Center
sts	Includes the site definition configurations for: Team Site Blank Site Document Workspace
Wiki	Wiki

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.

PERMISSION POLICY LEVEL	ADD AND CUSTOMIZE PAGES	BROWSE DIRECTORIES	MANAGE LISTS
Full Control	Grants	Grants	Grants
Full Read	Blank (neither grants nor denies)	Grants	Blank (neither grants nor denies)
Deny Write	Denies	Blank (neither grants nor denies)	Denies
Deny All	Denies	Denies	Denies

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.

PERMISSION LEVEL	ADD AND CUSTOMIZE PAGES	BROWSE DIRECTORIES	MANAGE LISTS
Full Control (Owners group)	Yes	Yes	Yes
Design	Yes	Yes	Yes
Manage Hierarchy	Yes	Yes	Yes
Approve	No	Yes	No
Contribute (Members group)	No	Yes	No
Read (Visitors group)	No	No	No
View Only (Viewers group)	No	No	No
Limited Access	No	No	No

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

SPD Licensing 101

spdblog — Sat, 15 Nov 2008 01:44:41 GMT

We often get questions from you about pricing, licensing, purchasing, etc., so we decided to compile a list of issues we hear most frequently from you in these areas and provide you all with a high level guide for these questions. Most of this information is available across other Microsoft and Office sites such as the SharePoint site, Microsoft Support, and TechNet, but this summary can serve as a good reference. The content below is organized in the following areas: Trials, Pricing, Purchasing, Activation, Licensing and Support.

TRIALS

Everybody likes to try a product before buying it, so we give you two choices: test drive the product or download a trial.

One of the easiest ways to learn about SharePoint Designer is to test drive SharePoint Designer. We use Citrix technologies to allow you to test our products directly on some of our own servers, so all you need is a browser. It will take just about 60 seconds on a broadband connection to get you up and running, after which you will see the following screen.

Just click on the Office SharePoint Designer 2007 link and, less than second later, you will be up and running, ready to use SharePoint Designer. It really is that easy.

The second option you have is to download a trial version. This allows you to use the product for 60 days. As the Licensing and Support page explains, trial versions are for evaluation purposes only and the product goes into reduced functionality mode at the end of the trial period. When downloading your trial software, you will receive the product key that will allow you to install and activate the trial software, as seen below.

Be sure to read the Frequently Asked Questions about the trial versions.

PRICING

SharePoint Designer is licensed per desktop (just like Office). This is in contrast to the Client Access License (or CAL) and Server model that applies to SharePoint servers. Interestingly, SharePoint Designer is the only product in the SharePoint product family that is also available outside of Microsoft’s Volume Licensing programs as part of what is called FPP, or “Fully Packaged Product,” the retail SKU that ships in the cool plastic box. One important thing to point out is that, while the phrase “Volume Licensing programs” sounds as if it only applies to Microsoft’s large enterprise customers purchasing hundreds of licenses, the Open License program actually covers organizations needing as few as five desktops. Of course, you can always buy just one or two licenses as well.

As a product part of the Office family, there are two types of pricing that apply to SharePoint Designer: the estimated retail price and the upgrade price. As of November 2008, these prices are:

· Estimated Retail Price: $299.95

· Upgrade Price: $159.95

Products that qualify for the upgrade price include Microsoft FrontPage 2000-2002, Microsoft Office FrontPage 2003, Microsoft Works 6.0–10, Microsoft Works suite 2000–2006 or later, any 2000-2007 Microsoft Office suite, and any Microsoft Office XP suite. For more details, visit the official pricing and upgrade information page of Microsoft Office.

PURCHASING

Buying SharePoint Designer is actually very easy since you can buy it online.

Be sure to check out the system requirements. In addition, make sure to explore if one of Microsoft’s Volume Licensing programs is best for you, especially if you are planning on acquiring five or more licenses or if you need assistance from the Microsoft License Advisor or a reseller.

ACTIVATION

We ask you to activate the software to verify that your installation is performed with a genuine Microsoft product. We have tried to make product activation as simple and painless as possible with the Activation Wizard. Before we discuss any of the issues you may face during activation, let’s define “Reduced Functionality Mode.” Reduced functionality mode happens when a trial period ends or a product has not been activated before the end of activation grace period. In this mode, the product will function similarly to a document viewer, and you will notice that many menu items become unavailable. No files or documents are affected however, and you can easily get out of this mode by activating your product.

Here is a summary of the key KB articles related to activation that will be mentioned below:

· KB Article 828958 is a good set of resources on Microsoft Office activation. You can get to almost all of the KB articles from there, so it is a good page to keep handy.

· KB Article 927921 includes Frequently Asked Questions about Activation and about reduced functionality mode.

· KB Article 836178 helps with the “Invalid Product Key” error.

· KB Article 919895 helps with a variation of the “Invalid Product Key” error and other problems with the Activation Wizard.

For the rest of this topic we will focus on some of the most common issues we have seen from your support questions:

· “Invalid Product Key”: Ok, first of all, please double check the characters you type against your product key to make sure yours is not a simple data entry error!

· You have exceeded the Activation Limit: The Office EULA allows the license to be activated on up to two computers. You may encounter this issue when you are replacing an older computer and are installing SharePoint Designer to your new computer. In this case, you should call the License Activation phone line to obtain a code to activate the license. If you are attempting to install SharePoint Designer onto more than the number of PCs allowed by the EULA, then you will need to purchase additional licenses. Please note that we are not listing the phone numbers for License Activation here. The correct number for you is based on several factors, depending on whether you purchased SharePoint Designer in retail or Volume License, and more obviously, it depends on your region. If you are located in the United States, then a good place to start is in the Microsoft Office Activation page. If not, please visit the main Microsoft Office and SharePoint page for your region.

· “Invalid Product Key” error message when providing the key (pre-installed software or mixing products and keys): This problem is covered in KB Article 836178. When you start a 2007 Office program, you may be prompted to provide the product key, but after entering it you get the error message “You have not entered a valid product key. Please check the number located on the sticker on the back of the CD case or on your Certificate of Authenticity” or you may get the message “Please wait while activation wizard initializes” after which the activation process hangs. In these cases, the likely reason is a pre-installed copy of the software. The problem is solved by uninstalling the previous installation and reinstalling. Make sure that you are not entering a key for a product different than SharePoint Designer. Keys are assigned to a specific product and are not interchangeable. Also, double check that you are not using a key that has exceeded its activation limits.

· Reactivation required after significant changes to the PC: The Activation Wizard creates a hardware identification that represents the configuration of your computer at the time of activation. Over time, especially if you have made significant changes to the configuration of your computer since the original activation, the Activation Wizard may require you to reactivate. Please refer to KB Article 927921. Note that most minor changes to your computer won’t cause you to have to reactivate.

· “Invalid Product Key” error message when running the product: If you get the error “Your software cannot be activated because the Product Key you installed with is not valid. Please uninstall the software and reinstall it using a valid Product Key” visit KB Article 919895. This is a more complex issue that requires you to try several methods to solve the problem.

· You are unable to activate your license because of some other problem: The KB Article 919895 mentioned above also helps with a few problems that are not as common:

o The Activation Wizard disappears, or it does not start but you don’t get any messages.

o You get a communication related error.

o You get an error message stating that the “confirmation ID is invalid” after activating your product over the telephone.

o The product starts in reduced functionality mode and you get the error message “2007 Microsoft Office system is expired. In this expired state, many features of the product are unavailable until you convert to the full product. Click Convert to begin the conversion process now” after running the Office Activation Wizard.

o When it is not apparent what the reason is for not being able to activate your software, it is possible that the OPA12.DAT file, which holds the licensing information, has become corrupted and needs to be rebuilt. You can just delete the file to force it to be recreated. Make sure NOT to delete the OPA12.BAK file.

o Again, read KB Article 919895 if you experience any of these scenarios.

· You are unable to convert a trial version to a full product: Conversion is the process that happens when you finish evaluating the trial version and decide to purchase the full product. In this case, you are required to provide a product key that you have purchased. However, some trial versions of the product cannot be converted, so you must uninstall the trial version and then install the full product separately. For more information, visit the Microsoft Office Activation page.

· Issues using SharePoint Designer over Terminal Server: You may be encountering the message “This copy of Microsoft Office SharePoint Designer cannot be used on Terminal Server. Please contact your local authorized Microsoft retailer for more information.” This message occurs because SharePoint Designer requires the use of Volume Licensing key to run on a Windows Terminal Server. Refer to KB Article 924622 for more information.

LICENSING

Software licensing can be complicated. You may want to keep these resources handy and provide them to your purchasing department contact when considering SharePoint Designer.

· Microsoft License Advisor located at http://www.microsoft.com/licensing/mla/default.aspx

· SharePoint Product Licensing at http://www.microsoftvolumelicensing.com/userights/ProductPage.aspx?pid=123: This page includes comprehensive information about SharePoint licensing. The page also includes some of the changes relevant to those of you with licenses of SharePoint Designer interested in using FrontPage, or to those of you interested in the Software Assurance migration path for FrontPage 2003.

SUPPORT

Support for SharePoint Designer is available over email, online, or over the phone. Use the following site to get support for SharePoint Designer in your region.

· Support Site, located at http://support.microsoft.com/common/international.aspx?rdpath=1&gprid=11677

WRAP UP

There you have it. Again, you can download this information as a Microsoft Word document here.

Page Versioning v2

spdblog — Sat, 08 Nov 2008 02:44:03 GMT

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.

Calling a WCF Service from a SharePoint Workflow (using Visual Studio)

spdblog — Mon, 03 Nov 2008 01:33:41 GMT

Greetings all, Alex Malek here - I'm a member of the SharePoint workflow team. This week at PDC, I did a breakout session on how to call an external system from a SharePoint Workflow. Let's walk through what that process looks like!

My Setup:

Office SharePoint Server (Express Setup)
Visual Studio 2008 Professional Edition
- Pro or better is required for the SP Workflow Tools

Note: I've already gone and created a WCF Service called "EmployeeUpdate” that has a single Operation called "UpdateEmployeeDB"

Step 0: Create a new SharePoint Workflow

Click “New Project” in the VS File Menu
Under the "Office/2007" group, choose "SharePoint 2007 Sequential Workflow". I've called my workflow "SharePoint Workflow 1”

Make your way through the wizard, and pick a site to test the workflow against. Then click Finish.
You'll now have a blank workflow to work with.

Step 1: Add a Service Reference to your Project

The easiest way to work with a WCF from .net is to have VS create a “proxy class”, which abstracts all the service calls behind a nice interface. You can do this easily using the “Add Service Reference” feature.

In the "Project" menu, click "Add Service Reference".
Paste in the address for your service and click "Go".
Give your reference a friendly name and press OK - I've chosen "CustomEmployeeDatabase”.
Once the file dialog goes away, you’ll notice a new child in your project pane, called “Service References”. If your service changes at some point, just right click your reference and choose “Update Service Reference”

Step 2: Register this endpoint with SharePoint

Creating the Service Reference endpoint also adds a "App.config" file to your local project, with a "System.ServiceModel" element. However, SharePoint doesn’t read from app.config files, so for SharePoint to be able to call this endpoint, you need to copy that configuration data to your local web.config.

Open web.config in VS for editing. You can find the file in the "\inetpub\wwwroot\wss\VirtualDirectories\80" directory, where 80 corresponds to the port of your SharePoint application.
Copy the "System.ServiceModel" element from app.config into web.config. If you already have a "System.ServiceModel” element, you’ll need to merge the <Bindings> and <Client> elements in manually.
To complete your changes, open a windows command window (Start/Run/cmd.exe) and type "iisreset", which will cycle the sharepoint web application, so it can pick up the web.config changes.

Step 3: Use a Code Activity to call the WCF service endpoint

Since SharePoint is built on .net 3.0, it is not supported to use the new Send/Receive Activities that were added as part of .net 3.5. Instead, we’ll use a code activity to work with the Service via code.

Drag a "Code" activity to the workflow designer canvas.
Next, double-click the activity to generate the code handler.
You can new up the service proxy client by using the proxy class name you gave.

CustomEmployeeDatabase.Workflow1Client client = new CustomEmployeeDatabase.Workflow1Client("WSHttpContextBinding_IWorkflow1");

4. Since my service is local, I’ll use the default network credentials to interact with the service. You’ll need to modify depending how your service is secured.

client.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;

5. Last, but not least, you can now call your operation, just as if it was a local function.

string result = client.UpdateEmployeeDB();
client.Close(); <- don’t forget to close your connection

That's it! You can now hit F5 to test your workflow.

Wrap-up

There you have it - calling web services from SharePoint workflows. If you run into trouble, double-check that you properly copied the configuration information from app.config into your SharePoint web.config.

Thanks!
-Alex Malek

Best Practice to create designer friendly server controls

spdblog — Sat, 04 Oct 2008 01:24:08 GMT

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:

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" ...>

<asp:BoundColumn ... />

...

</Columns>

</asp:DataGrid>

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

Declarative Workflows and User Context

spdblog — Mon, 29 Sep 2008 07:02:42 GMT

My name is Darren and I’m one of the workflow testers for SharePoint Designer. One of the ways that SharePoint Designer workflows operate that seems to be a point of confusion that I keep hearing about is that certain actions don’t always work when someone expects them too. There are a number of reasons that this can happen, but the main one I would like to blog about is user context the workflow runs under.

The basic thing to remember is that declarative workflows (the one’s created by SharePoint Designer) always run impersonating the user who started the workflow. So if I’m a contributor and I make an edit to a list item and that triggers a workflow then that workflow runs as me and has the ability to do everything that I do. Where this can get challenging is in cases where the workflow tries to do something I couldn’t do on my own, like make a change to a list I don’t have permissions to, since it also has the same limitations I do. The reason we do this is to protect against things like elevating someone’s privileges to something they might take advantage of or get information they shouldn’t be able to see.

Now this seems simple at first, but it is limiting what can be done by a declarative workflow in some more complicated scenarios like triggering a workflow base on an anonymous submission to a list. The main way the people have worked around this (either intentionally or unintentionally) is get a workflow triggered by the SharePoint System account (the account used to run the SharePoint web application) which has full access to everything. This is accomplished by using email enabled lists, running a custom form (i.e. InfoPath) that submits data to a list, or some other custom code (or even custom workflow actions that elevate themselves for certain tasks). This was fine until we discovered a security problem in declarative workflows that we had to fix in SP1. One effect of this change is that the SharePoint System account is no longer allowed to trigger declarative workflows.

This change effectively broke some people’s workflows and we knew it would, but that was better than allowing the security problem to remain. Some of these scenarios can be fixed by changing the custom code or updating the submission form. But one that can’t is lists that have email enabled on them add the items to the list as the admin account. With SP1 those can’t start workflows and administrators have no way of changing the account items get added as. So as part of the SharePoint Infrastructure Public Update we allow for that scenario base on a stsadm.exe command that sets a property to allow emailed items to trigger workflows as the person who last saved the workflow to the site. This will also be rolled up into SP2.

To sum up . . .

· Declarative workflows run as the person who triggered the workflow either manually, or by adding or editing an item.

· Individual workflow actions can be made to elevate permissions.

· The RTM version of the server allowed workflows to run as SharePoint System, but had a security vulnerability.

· In SP1 the security problem was fixed, but declarative workflows can no longer be triggered by the SharePoint System account.

· In the SharePoint Infrastructure public update box administrators can allow email enabled lists to trigger workflows as the last person to save the workflow when an item is created via email. Run “stsadm.exe –o setproperty –propertyname declarativeworkflowautostartonemailenabled –propertyvalue yes” on the patched server to enable this.

So when building a declarative workflow take a moment to consider under what user context the workflow is running so you can better plan what the workflow is able to do.

Using “Disable Output Escaping” in Data View

spdblog — Sat, 20 Sep 2008 15:47:00 GMT

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 &:

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

Use JavaScript to enable formatting of Data View UI controls

spdblog — Wed, 17 Sep 2008 00:43:00 GMT

Hi, Andy Lewis here again. Today I'm here to talk about how to work around a certain type of challenge you might run into when trying to customize the user experience (UX) of a form in a SharePoint application.

When I began trying to make the leap from generic web development into SharePoint development, I found I needed to get used to the fact that I no longer had direct control of some of the key building blocks of the UX: the HTML controls. In SharePoint, the HTML controls are emitted out of server-side controls. You don't have direct control of the markup that is sent to your customer's web browser.

Note: In this article, some of the material that explains how to perform the more basic tasks is hidden from view by default if you have JavaScript turned on. If you want to print this article with all the material included, click here: Show All.

My users need more pixels!

As I began getting used to working within the context of SharePoint, one challenge I faced was figuring out how to make even simple adjustments to the UX, such as modifying the width and the height of a user interface (UI) control. Simply put, I wanted to make my customers more comfortable by giving them more pixels!

Modify the size of a text-value field

For some fields, their presentation is fairly easy to adjust. For example, in Modify the lengths of List Form Fields, John Jansen showed how to use a little CSS to modify the width of the textbox field used to edit the Title value of a SharePoint list.

While playing around in code view, I noticed another option. The SharePoint:formfield tag accepts an attribute called DisplaySize. If you add this attribute to the tag (for example DisplaySize="100") in your custom form, then you can also make a text value field (such as the standard Title field), longer. (This attribute does not work for all SharePoint list column types.)

But let's move on to how to make a customization that is a bit more challenging.

Expand size of the lists for a multi-value lookup column

I was recently working on a custom form that included a multi-value lookup field. SharePoint renders the UX for this kind of field in the form of two select list controls and two button controls to move items between the two lists.

The catch is that these controls are wrapped inside other HTML tags, one of which blocks CSS from working because it has a hardcoded style in it. The structure that is sent by the server to the web browser looks something like like this if you edit the source in SharePoint Designer and selected one of the select controls:

<span>

<table-ms-long>

<tr>

<td.ms-input>

<div>

While working on the application I was building, I was feeling really motivated to make the two select controls bigger because my users would be choosing from a long list of items, some of which would be very wide. In short, I wanted to be able to offer the customer wider and taller controls like these:

I expect that this is probably a common UX enhancement that site owners want to make, which is why I decided to write this article.

The site

To follow the examples below, you need to create a Team Collaboration site that includes:

A custom list called Projects
A Tasks list (included by default in a new Team site) that has a multi-value lookup column that looks up the Title from the Projects list.

Create custom NewForm for the Tasks list

Important: Before you modify any of the three core list forms (DispForm, EditForm, or NewForm), you must always remember one rule: Never delete the ListFormWebPart object. If you do, you may break your list! In the steps below, I'll explain how to hide this form and replace it with your own custom form.

Create the select-container style that defines the width and height of the select controls the user uses to modify values in the multi-value lookup column:
1. On the File menu, point to New, and then click CSS.
2. Add the following code to the new CSS file:
```
.select-container div {
   width:300px;
   height:150px;
}
```
3. On the File menu, click Save and then use the Save dialog box to save the file as shared_styles.css in the root directory of your site.

Create the removeLocalStyleAttributes() function that you will use to remove the hardcoded width and height style attributes that block your select-container style from working correctly:

On the File menu, click New, click JavaScript, and then click OK.

Add the following code to the new JavaScript file:

function removeLocalStyleAttributes() {
   var coll = document.body.getElementsByTagName("div");

   for(x=0;x < coll.length; x++)
   {
      if(coll[x].className == "select-container") { 
         var collDivControls = coll[x].getElementsByTagName("DIV");

         for(y=0;y < collDivControls.length; y++)
         {
            collDivControls[y].style.width = null;
            collDivControls[y].style.height = null;
         }
      }
   }
}

On the File menu, click Save and then use the Save dialog box to save the file as shared_functions.js in the root directory of your site.

In the Lists/Tasks folder, open NewForm.aspx.
Hide and close (do not delete!) the WebPartPages:ListFormWebPart object. How?
1. In Design view, right-click the WebPartPages:ListFormWebPart object and then choose Web Part Properties from the properties menu.
2. Expand the Layout group.
3. Check the Close the Web Part and Hidden checkboxes.
4. Note: the WebPartPages:ListFormWebPart object is still visible in SharePoint Designer, but it will be hidden to customers of your site.
Insert a new WebPartZone at the top of the inside of the asp:Content PlaceHolderMain tag. How?
1. In Code view, find this asp:Content tag: <asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">. Place the cursor immediately after this asp:Content tag.
2. On the Insert menu, click SharePoint Controls, and then click Web Part Zone.
3. Switch to Design view to see the new WebPartZone.
In the new WebPartZone you just created, insert a New Item Form DataFormWebPart that includes the Projects field and any other fields you need in the form. How?
1. In Design view, select the WebPartZone you just created.
2. On the Data View menu, click Insert Data View.
3. Click the link that appeared in the middle of the Data View: Click a data source in the Data Source Library, and then click show Data.
4. In the the Data Source Library task pane, in the SharePoint Lists group, click the Tasks list, and then click Show Data.
5. Press and hold down the CTRL key as you select the following fields from the Data Source Details task pane: Assigned to, Title, Priority, Status, % Complete, Description, Start Date, Due Date, and Projects.
6. Click Insert Selected Fields as, and then click New Item Form.

In Code view, add the following asp:Content tag to the page:

<asp:Content contentplaceholderid="PlaceHolderAdditionalPageHead" runat="server">

   <link rel="stylesheet" type="text/css" href="../../shared_styles.css" 
      mce_href="../../shared_styles.css"> 

   <script src="../../shared_functions.js" mce_src="../../shared_functions.js" 
      type="text/javascript"></script>

   <script type="text/javascript">
      _spBodyOnLoadFunctionNames.push("removeLocalStyleAttributes");
   </script>

</asp:Content>

In Code view, in the XSL code of the DataFormWebPart, find the SharePoint:formfield tag for the Projects field and wrap it with a div tag that has select-container as the value of its class attribute:

<td width="75%" class="ms-vb">
   <div class="select-container">
   <SharePoint:FormField runat="server" id="ff5{$Pos}" ControlMode="New" 
      FieldName="Projects" __designer:bind="{ddwrt:DataBind('i',concat('ff5',$Pos),
      'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Projects')}" />
   </div>
   <SharePoint:FieldDescription runat="server" id="ff5description{$Pos}" 
      FieldName="Projects" ControlMode="Edit" />
</td>

Closing

Thanks for taking the time to read this article. What is your favorite JavaScript tip? If you have a blog article about it, please post a comment and link to your article.

How? links

I'd be interested in hearing your opinion on a subject I've been wondering about for a while. You will notice that in some of my articles, including this one, I offer what some might call "remedial" instructions, but I hide them behind a JavaScript "How?" widget to keep the text from getting bogged down, especially for more experienced customers who don't need the extra help.

The question on my mind is this: How many of you actually find these "How?" instructions useful? I sometimes feel tempted to save myself the fairly significant amount of time required to enumerate these steps. And yet, I'm not sure that a statement like this is going to be helpful enough for many folks: In the new WebPartZone you just created, insert a new DataFormWebPart New Item Form that includes the Projects field. What do you think?

New job

Finally, I'm going to be transitioning to a new role here at Microsoft. I just started working for a team that produces user education content for Visual Studio Team System. I want to thank the SharePoint Designer product team for so many things. They invited me to participate here on this blog, and they have given me support, guidance, and feedback on my work. And of course, special thanks to you for reading and participating with your comments and sometimes your very useful corrections.

Starting a new job always makes me think about how I've been doing my work, and what things I want to try doing differently. So I'm using this change as a kick in the pants to myself to put up my own shingle and set up a blog (finally; I am such a late adopter to this trend!). As of this writing, there is not much there, but I will endeavor to add more to the blog and keep it fresh in the future.

Andy