Today’s diagram is probably best considered a work in progress.
We created the following diagram as a prototype, to see if we could use large-scale static graphics as aids for developers to visualize the SharePoint object model hierarchy and the relationships between classes within it. As an experiment, we took the subset of classes available in sandbox solutions, and, starting from a handful of the most important classes, laid out the Microsoft.SharePoint namespace hierarchy.
The results were mixed: we quickly realized that, as recursively nested as the SharePoint object model is, arbitrarily picking starting points (even important classes such as SPWeb and SPList) and presenting a single hierarchical view of the object model from there probably isn’t going to be that useful long-term for developers. Locating a specific class was difficult. Also, in order to conserve space, we omitted the names of the members used to access a class from another class; in doing so, we inadvertently stripped off an important layer of information about the relationship between the classes.
However, the diagram does provide a useful general reference for how the major classes of the SharePoint namespace are structured, so we’re presenting it here as a free download. The diagram is 34” by 44”, and available as a Visio drawing or pdf file. You can download the larger versions in a zip here on the blog. In the comments, tell us what information you’d want to help you visualize a complex object model like SharePoint, be it in a static diagram like this, or an interactive application that enabled you to select what to display.
Ribbon customizations, deployed as custom actions, in SharePoint 2010 can be categorized in two ways: filtered and unfiltered. A filtered custom action is one that uses the RegistrationId and RegistrationType attributes, for example to target a specific list. An unfiltered custom action is one that does not use these attributes. Ribbon custom actions are handled in different ways depending on the type. Both filtered and unfiltered custom actions are passed into the SPElementProvider internal class. SPElementProvider retrieves the Server ribbon XML from the custom action and sends it to the internal classes SPToolbar and SPUIProcessor depending on the type of custom action.
A custom action has two pieces:
For filtered custom actions, the UI and handlers are generated in the following way: SPToolbar class takes the handler data, which is stored in <CommandUIHandlers> in the XML, and the user interface extension data, which is stored in <CommandUIExtension> in the XML, and passes both to the SPRibbon class. The SPToolbar also takes any V3 custom action that applies and creates handler data, generates callback IDs, and passes the resulting handler data into the SPRibbon class. The SPToolbar generates user interface extension data (in the form of buttons) from the V3 custom actions that apply in the Custom Commands tab. Commands are generated for these buttons with the corresponding callback IDs that were generated for the command handlers. SPRibbon then renders script onto the page that takes the handler data (supplied by SPToolbar from the various custom actions) and wires it up to the internal CommandUIPageComponent on the client side. The SPRibbon class also renders the user interface piece of the filtered custom actions so that they can be consumed by the RibbonBuilder on the client side when it builds the ribbon.
For unfiltered custom actions, the UI and handlers are generated in the following way: The client side RibbonBuilder retrieves data from the commandui.ashx HTTP handler on the server. This data is a merge of the out of the box cmdui.xml file and any unfiltered custom actions that apply on the current SPWeb. The RibbonBuilder client object then merges this data with the filtered custom action extensions that the SPRibbon server control rendered and then builds the client Ribbon control from this merged data. The client object CommandUIPageComponent then retrieves unfiltered handler data from commandui.ashx and merges it with the filtered handler data that was rendered by the SPRibbon server control on the page. Commandui.ashx gets its data by querying the SPUIProcessor which produces its data by merging out of the box cmdui.xml data with the unfiltered custom action handler and user interface extension data.
The end result is that the page has a client Ribbon control that is built from a merge of cmdui.xml, unfiltered and filtered user interface extension data, and a CommandUIPageComponent that has handlers that are a merge of the unfiltered command handlers from commandui.ashx and the filtered command handlers that were rendered onto the page by the server side SPRibbon class.