SharePoint Development from a Documentation Perspective
The guys at OfficeZealot.com have generously agreed to host a few more of the large-size diagrams I’ve created for internal usage. So I’m offering up several object model maps for download. These are poster-size (11” by 17”) diagrams that illustrate key objects and namespaces in the SharePoint environment, suitable for sticking up in your office or hanging in your home as fine art.
Each object model map was created in Visio, but the downloads are PDFs for ease of viewing and printing.
Just click on any or all of the links below to download the maps you want. And leave me a message in the comments section telling me what you thought of the format, design, layout, etc. of the diagrams. Thanks.
· The Windows.SharePoint.Workflow Namespace
Workflow is another area you’re going to be hearing a lot about this release. The diagram illustrates the classes and members of the Workflow namespace, which you’d use to associate, initiate, and otherwise manage the workflow templates and instances in a Windows SharePoint Services deployment.
· The Windows.SharePoint.SPContentType Object
This object model map highlights the members and child objects of the SPContentType object. Content types are a core concept for this next release of Windows SharePoint Services, as I explain here. This object model maps compliments the conceptual diagrams of content types I offered for download here.
· The Microsoft.Office.RightsManagement.InformationPolicy Namespace
I haven’t talked about information policy on this blog yet, but there’s plenty of material in the Office SharePoint Server 2007 (Beta 2) SDK to fill you in. (Start here.) This diagram illustrates the classes and members of the InformationPolicy namespace, which you’d use to manage the policies, policy features, and policy resources on a SharePoint Server 2007 installation.
I’ve still got a few more diagrams to make available; check back early next week for more full-color, absolutely free goodness.
Written while listening to Greg Dulli : Amber Headlights
The title pretty much says it all. For some of our earlier, internal technical events, I created a number of large-format (11” by 17”) technical illustrations to explain the more complicated aspects of enterprise content management in a SharePoint environment. The two posters I’m offering for download today deal with content types, a core concept in Windows SharePoint Services V3 that I’ve blogged about here. If you’re planning on using content types, I think it’ll be worth your while to take a look at these.
As you can probably tell, I created the posters with Visio. I then converted them to PDF format using Visio 2007 (Beta)’s spiffy new Publish to PDF feature. I have to say I’m fairly impressed with the results. These are pretty complex diagrams, and as far as I can tell, Visio converted them flawlessly to PDF. Well done.
Using Columns and Content Types to Organize Your Content in Windows SharePoint Services (version 3)
This diagram explains the relationship between site and list content types, as well as content type ‘inheritance’ and customizing/deriving content types. It also illustrates how you can use site columns in your content types to ensure data uniformity, and how content type reference site columns and list columns.
Using Content Types in Windows SharePoint Services (version 3) and SharePoint Server 2007
Explains what content types are, and the advantages of using them to categorize and manage your enterprise content. Illustrates the conceptual structure of the various feature information you can encapsulate in a content type, such as columns, document templates, workflows, and custom solutions information such as forms and information policy.
Note that these diagrams were created to be used with Adobe Reader 7.0, and will undoubtedly appear best using that version. I haven’t tested to determine if the diagrams display or print accurately in earlier versions.
If you download either (or both) of the posters, take a second and let me know what you think of them in the comments section. Were they useful in explaining the various concepts they illustrated? Would you like to see something like this rolled into the SDKs at some point? I’m very visually-oriented; most of the technical illustrations I create start with me jotting something down on a napkin, to explain a concept to myself. But I have no idea if that’s true of developers in general. Are illustrations helpful in technical documentation like SDKs? Let me know what you think.
And special thanks to Steve and Ryan and all the good folks at Office Zealot, who graciously agreed to host these diagrams for downloaded. I greatly appreciate it. Take a few minutes and visit their site; they’ve got tons of interesting content for the Office developer. It’s time well spent.
And check back here next week. I hope to get some object model maps done for a few of the SharePoint namespaces, and I’ll make those available for download once I do.
Written while listening to Isobel Campbell and Mark Lanegan : Ballad of the Broken Seas
One of the major new concepts in Windows SharePoint Services V3 is content types. They're a core concept that enables a lot of the functionality in both Windows SharePoint Services and Office SharePoint Server 2007, so they seemed like a logical choice to talk about.
A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way. Basically, content types include the columns (or fields, if you prefer) you want to apply to a certain type of content, plus other optional settings such as a document template, and custom new, edit, and display forms to use.
You can think of a content type as a refinement and extension of a Windows SharePoint Services 2.0 list. The list schema defined a single group of data requirements for each item on that list. So in Windows SharePoint Services 2.0, the schema of an item was inextricably bound to its location.
With content types, you can define a schema for types of content, but that schema is no longer bound to a specific location. And to look at it in reverse, each SharePoint list is no longer limited to a single data schema to which the documents stored there must adhere. You can assign the same content type to multiple document libraries, and you can assign multiple content types to a given document library. Content types, in essence, let you:
· Store the exact same type of content in multiple locations
· Store multiple types of content in the same location
Site and List Content Types: Parents and Children
There are two different levels of content types I should mention: site content types, and list content types. Think of site content types as templates, and list content types as instances of those templates. You define site content types at the um, site level, hence the name. Since site content types aren't bound to a specific list, you can assign them to any list within the site you want. The site at which you define the site content type determines the scope of that content type.
List content types are more like instances, or single-serving content types. When you assign a site content type to a list, a copy of that content type is copied locally onto the list. That's a list content type. You can even tweak a list content type so that it's different from its site content type 'parent'. Also, you can create a content type directly on a list, but it's a one-off. You can't then assign that list content type to other sites or lists.
One other thing about site content types: you can base content types on other site content types. For example, Windows SharePoint Server comes with a built-in hierarchy of content types for basic SharePoint objects, such as Document, Task, Folder, etc. You can create your own site or list content types based on one of these site content types. Ultimately, all content types derive from the grandfather of them all, System.
Also, if you make changes to a site content type, Windows SharePoint Services includes a mechanism whereby you can 'push down', or propagate those changes out to the child content types (be they site or list content types). Doesn't work the other way, though; no pushing changes to child content types up the family tree.
E is for Extensible
You can see how content types were designed to encapsulate and modularize schema settings in Windows SharePoint Services V3. One very powerful aspects of this is that you can use content types to encapsulate whatever custom data you want to include in them. The content type schema includes a <XMLDocuments> node, which you can use to store nodes of any valid XML. As far as Windows SharePoint Services is concerned, the contents of the <XMLDocuments> node is a black box. Windows SharePoint Services makes no attempt to parse any of the XML documents you store there; it simply makes sure that they are included in any children content types, such as when you assign the content type to a list.
The <XMLDocuments> node was designed to be utilized by third-party solutions. Use it to store information pertinent to any special settings or behavior you want to specify for a certain type of content. Office SharePoint Server uses this mechanism to store information various features need, such as information policies and document information panels, among others. You can programmatically access a SharePoint item’s content type, and from there access the XML documents include in the content type.
Find Out More
To learn out more about content types, browse the topics included in the Content Types section in the Windows SharePoint Services V3 (Beta) SDK.
And here’s a few places content types are utilized to facilitate Office SharePoint Server functionality:
Using content types to specify document information panel.
Using content types to specify document to page converters.
Using content types to specify information policy.
Written while listening to Bob Mould : Body of Song
Well, as you've probably already heard, yesterday was a big day for us here, what with the Beta releases of Office 2007, Windows Vista, and Windows Server "Longhorn". What you may not realize is that the Office developer documentation team has been working overtime to make sure there's lots of in-depth developer documentation ready to highlight all the great developer features built into Office this time around.
And with that, I take great pleasure in announcing the two projects that have been consuming most of my professional life for the past year: the Windows SharePoint Services V3 (Beta) and Office SharePoint Server 2007 (Beta) SDKs. Each SDK comes in two flavors: as a downloadable help file, or as online topics on MSDN.
To download the SDKs, go here:
To browse the SDKs online at MSDN:
But that's not all. We've totally redesigned the Office Developer Center and its sub-sites, and posted tons of new developer content for the 2007 Office System. (And I mean 'we' in the most general, corporate sense of the word, as I really had nothing to do with it.) Go take a look and see what's new for 2007 for your favorite Office app. For example, how about that new Office SharePoint Server 2007 Developer Center?
We've even launched a brand-spanking new developer portal to give Windows SharePoint Services developers a place of their very own: the Windows SharePoint Services Developer Center. And it too has lots of articles, demos, and screen casts to bring you up to speed on V3.
It's actually a little intimidating to look at how much developer extensibility there is in Windows SharePoint Services and Office SharePoint Server this time around. So where do you start? Over the next few weeks I plan to excerpt some of the conceptual material from the SDKs to highlight the areas I've been documenting: the enterprise document management features. After that, if all goes well, I'll be able to give you previews of information that didn't make it into the Beta releases of the SDKs, but will be included in the final release.
But for now, dig in. There's plenty to keep you busy.
One article you might notice on both SharePoint portals is one that goes by the catchy title of Developer Introduction to Workflows for Windows SharePoint Services V3 and SharePoint Server 2007. This article pulls together information from both SDKs, as well as Windows Workflow Foundation, Office SharePoint Designer 2007, and InfoPath 2007 developer documentation, to provide a high-level overview of how workflows are implemented in the SharePoint Server and Office client environment. I wrote the article to give developers a unified picture of workflows in Office, and the tools and technologies you can use to create them. If you're interested at all in the new workflow foundation functionality, give it a read. And, as always, if you read it, please let us know what you thought by rating the article.
Written while listening to The New Pornographers: Electric Version
Okay, so it’s been months since I last blogged. But that’s not because I haven’t been busy, or haven’t wanted to. I’ve just been working on stuff that I couldn’t talk about. But all that’s about to change.
Watch this space.
Written while listening to: The Twilight Singers : Powder Burns