Remember DateTime Casting With SP.ListItem Modified Property

I had this come up with a client this morning. To get down with it, consider the following client object model code:

ClientContext clientContext = new ClientContext(“http://test”);
List list = clientContext.Web.Lists.GetByTitle(“TestList”);
ListItemCollection listItems = list.GetItems(CamlQuery.CreateAllItemsQuery());
ListItem item = listItems[0];

// pay attention to this!
DateTime modifiedDate = (DateTime)item[“Modified”];

// Should use include to only use the properties that are required


In the above we have a couple things going on. Firstly, a ClientContext object is instantiated to represent the context for SharePoint objects and operations. Next, we are getting a SP.List object by using the ListCollection.GetByTitle method passing in the list name. Next, we are getting all the items from the list by using the SP.List.GetItems method then passing in the CamlQuery.CreateAllItemsQuery method. Indexing the collection, we are getting a test SP.ListItem. Now this is where the context of this post comes into play. If you are getting the Modified property of the list item, you have to remember to explicit cast to a DateTime type (you could safely cast as well). If you don’t, the value **may** display empty (it’s not consistent across list types)!


SharePoint ECMAScript (Client Object Model) Empty List Helper

Lists are a lot more useful as data storage mechanisms in SharePoint 2010 since there are important relational features finally built into them. Coupled with the client object model features you can start to do some really nifty data manipulation with some quick, easy code. As such, I have been starting to build up a bunch of bulk list operations that I’m using in a static manner for both some internal as well as client applications.

In the below helper function, I am emptying the items out of a list. It’s actually probably better to abstract the list title to the emptyListHelper parameters so you can pass in a string in a shared manner, so that’s might be a good idea.

var siteUrl = ‘/AdamBuenz/EmptyItemsTest’;

function emptyListHelper() {
var clientContext = new SP.ClientContext(siteUrl);
var list = clientContext.get_web().get_lists().getByTitle(‘TestList’);
var camlQuery = new CamlQuery();
camlQuery.set_viewXml(“Some Value To Match Value100“;
this.listItems = list.GetItems(camlQuery);
clientContext.executeQueryAsync(Function.createDelegate(this, this.onQuerySucceeded), Function.createDelegate(this, this.onQueryFailed));

function onQuerySucceeded() {
var listItemEnumerator = this.listItems.getEnumerator();
while (listItemEnumerator.moveNext()) {
var item = listItemEnumerator.get_current();

function onQueryFailed(sender, args) {
alert(‘Request failed. ‘ + args.get_message() + ‘\n’ + args.get_stackTrace());



Free SharePoint Organizational Chart WebPart SimpleChart for SharePoint

I have written all sorts of organizational chart WebParts in the past leveraging various rendering engines and complex ruling, outputting in various formats with assorted hooked behavior wired to the org chart. Having studied users while they are interacting with the org chart software, something that I found is glitzy, flashy eye-candy org chart features have about an interest shelf-life of 5 minutes for the typical user. While numerous business circumstances can cultivate all types of useful material to incorporate into the software, they rarely make a long-term practical contribution to the applicability of the org chart software, and in my opinion deteriorate the direct usefulness. As by definition an organization chart is a diagram that shows the structure of an organization and the relationships and relative ranks of its parts and positions/job keeping it strictly within this scope is vital for product success.

So I decided to sit down, and write an organizational chart WebPart that just makes an org chart. That’s it. It draws an org chart. It doesn’t do anything else. But it sure can draw an org chart. A really simple one that is consummately faster than contestant WebParts.

To realize this requirement, I decided to utilize the Google Visualization API since it supplied fundamental minimum functions to integrate obligatory, decisive features. Using a primitive SharePoint list as the visualization data source it is also very unpretentious, generic and not irrevocably bound to an automated source. This obviously has pros and cons, but for me having control over the display is a big pro.

Outside of the lean features provided by the Google Visualization API, I wanted something that used a rendering engine that I didn’t have to maintain or even one that another company maintained and pushed out components as a shared library. I have had problems with that in the past with organizations using analogous libraries, and they might move a little quicker than I in retrofitting, so products reference discrepancy can occur.

Lastly, I wanted something small….a really concise solution not composed of numerous moving parts (under 10k packaged). Just a very maintainable, low chance of exception approach that had zero gold plating while staying within the realm of what a functional org chart should do. I wanted it as lean as possible, focusing not on features but on rendering speed.

Onto the SimpleChart WebPart!

The WebPart description file is Feature controlled, so activate the SimpleChart For SharePoint Feature from the  Site collection features:

9-29-2009 3-36-09 PM

One the activated the WebPart is pretty easy to find from the gallery:

9-29-2009 3-38-05 PM

Here are the default WebPart properties. Some of the properties will assume default values when not provided (like color etc.), others are necessary for the WebPart display.

9-29-2009 3-12-42 PM

Display Properties

The org chart has nominal configurable properties to manipulate the WebPart display:

9-29-2009 3-16-54 PM

(1) Allow HTML If in the SharePoint list feed, the strings are stored as HTML tags they will be rendered as HTML. Best to keep this on.

(2) Allow Collapse If you want to be really fancy, this makes the boxes collapse up and down. Oh la la.

(3) Background Color – For each element in the org chart the Hex Triplet (HTML Color) provided will apply style to the *unselected* boxes.

(4) Selected Color – For each element in the org chart the Hex Triplet (HTML Color) provided will apply style to the *selected* boxes.

Operational Properties

The other properties are related directly to the WebPart operation. In order to support a generic list datasource, the WebPart expects you to provide the SharePoint list name and associated field names, correlating to the properties of the user. Don’t worry about CAML delimiters; the WebPart will parse all the values correctly internally. So, before you start using the WebPart, make a list with:

  • Employee Name
  • Superior ID
  • Employee Title
  • Employee Phone
  • Employee Address
  • Employee Email
  • Employee City
  • Employee State
  • Employee Country

9-29-2009 3-19-06 PM

So what’s it look like? Here is a screenshot of my list data source:

9-29-2009 3-21-24 PM

Now in the above, take note that the TITLE FIELD IS CHANGED TO EMPLOYEE TITLE. I used a custom list as the base template. If you really want you can download it here. I didn’t want to have a field that had no relevancy in the list, so it is best to repurpose it to hold the employee title.

The output from this data in SimpleChart is:

9-29-2009 3-32-31 PM

Pretty much all the fields being used are self -explantory. Superior (Manager) ID is the integer that correlates to to the Employee ID of the desired branch, that is pretty much the only relational field. Obviously, toggling the color values you can make some pretty awful charts:

9-29-2009 3-41-40 PM

leads to this beauty:

9-29-2009 3-43-00 PM

If you want support, use the contact form and drop me a line, leave something in the comments, whatever. I can tailor probably tailor the part to your organization requirements as well if you need help.



Download is down, new version out 10/16/2009 COB.


You can download the new version here.

I am considering extending the data sources to use either profiles or AD DS lookups as well. If there is sufficient interest I might just do that. Leave feature requests in the comments! I generally will put them if I I get bored.