ARB Security Solutions » What Are The Biggest SharePoint API Mistakes?

Latest Free SharePoint Software

ARB Security Solutions regularly releases free SharePoint software, including WebParts, Client Applications, Framework Extensions, and other Miscellaneous Components.
The most recent freeware is:

Title: Simple SharePoint Rollup WebPart
Date Published: 10/22/2009

Previous Two Free WebPart Releases:

SharePoint Security Assurance Program™

For externally facing SharePoint deployments, security is an acutely important deployment concern. Learn how through daily security scanning, you can ensure external business users and partners that they can collaborate in confidence!

Security Assurance WebPart:

Start Audit Process With The SharePoint Security Assurance Program™

What Are The Biggest SharePoint API Mistakes?

The most prevalent SharePoint API mistake that I see is the lack of freaking Exist properties on proxy objects.

What do I mean?

One can’t do this in order to test, for example, whether a SPList object exists:

PLAIN TEXT

C#:

public static void DoesMyListExistIDunno()
{
SPWeb web = SPContext.Current.Web;
SPList list = web.Lists["Heres My List"];
bool areYouThere = list.{An Exists Property Would Be Sweet Wouldn't It?};
}

As opposed to this, a developer is forced to do this (or a mild variation of this, I am just using the LINQ because it looks fancy) which is lame:

PLAIN TEXT

C#:

public static bool InspectForList(string listName)
{
var results = SPContext.Current.Web.Lists.Cast<SPList>().Where(item => Equals(string.Compare(item.Title, listName, true), 0));
return results.Count()> 0;
}

What do you think is the most rampant and cumbersome? I am interested in what other people see as being a pain in the butt.

Article Or Research Filed Under General (Personal)| SharePoint Development.

10 Comments »

The use of sealed classes on everything I want to mock comes to mind

Comment by James Contusion — February 25, 2009 @ 2:25 pm
I think they should have provided 100% “dispose every time” SPWeb, SPSite, etc. objects. The SharePoint internals would work out whether the disposal method does anything (!!!), leaving we the API consumers, to dispose every time.

Much simpler rule to follow.

Also, I want them to change all the getters and indexers to methods, because it seems like everyone in the world assumes that getters and indexers return the same object every time. Example:

$web.Lists["Announcements"].Visible = $false
$web.Lists["Announcements"].Update()

Third, I’m not a fan of the way SPSite/SPWeb/SPList/SPListItem/etc are proxies to the real objects, i.e. that some of their data is stale, but other data is refreshed every time you ask for it. Good recent example, I had a bug where I a) ran $spListItem.File.MoveFile(“tosomewhereelse”), b) couldn’t use $spListItem anymore, because all methods returned errors, because the file it internally points to moved. So I had to manually get the item again. …This behavior is okay, if it’s consistent between methods; either consistently stale, or consistently fresh.

Fourth, I wish the Feature/Solution framework included a way to separately deploy configuration. This isn’t so much a mistake as a feature request, but everyone needs it, and maybe they should have picked this up pre-RTM.

Comment by Peter — February 25, 2009 @ 3:02 pm
Peter:

Your first one I TOTALLY agree on. The requirement for manual disposal is pretty ridiculous, but I think it’s more the poor implementation of IDisposal then anything. The solution of “more tooling” to ensure the disposal is pretty weak.

Second point, totally. I have run into that a TON.

Third point, haven’t run into it, but I see the point. I do understand it based on your example though, and the consistency would be a nice attribute!

Fourth point, I agree that this is a huge pain! I hope in the next revision this is taken care of.

Comment by Adam Buenz — February 25, 2009 @ 3:07 pm
Fifth, I wish CAML (query language) disappeared and was replaced with LINQ to CAML.

I wish the other CAML (every bit of XML everywhere) was replaced with code. We’re not getting any of the benefits of XML anyway, so why not instead of building a ListDefinition in XML, declare a ListDefinition class with a bunch of required getter properties? What’s the difference? What’s the disadvantage of code over XML?

Instead of declaring a Feature manifest in XML, why not move the data to the Feature Receiver class in a bunch of public read-only properties?

And I shouldn’t say that XML is the problem, or that you can’t generate the XML for SharePoint to use, like it always has–the problem is that I can see and am editing the XML manually, by hand.

Comment by Peter — February 25, 2009 @ 3:17 pm
Peter: Continually recompiling assemblies to update or modify a list definition is a hassle. I much prefer CAML, or at least an XML-based language for this. Luckily WSS4 will, most likely, replace CAML View schema with XSLT.

Also, I don’t see the big issue with writing the XML by hand. How would this change if you had to write the .NET code by hand? With John Holliday’s CAML.Intellisense you’ll get really good intellisense as well.

For a lot of CAML tasks you can also build the object in the Web UI and then extract the CAML required to put this in a feature.

.b

Comment by Bjørn Furuknap — February 25, 2009 @ 9:20 pm
I would reply in full, because there’s a lot to say about SharePoint development, but quickly: JavaScript-in-HTML-in-XSLT-inside-HTML gives me seizures.

Comment by Peter — February 26, 2009 @ 9:30 am
Rather than Where/Count, just use Any:
public static bool ListExist(SPWeb web, string listName)
{
return web.Lists.Cast().Any(list => string.Equals(list.Title, listName));
}

Comment by Keith Dahlby — February 26, 2009 @ 6:28 pm
[...] What Are The Biggest SharePoint API Mistakes? [...]

Pingback by Links (2/26/2009) « Steve Pietrek - Everything SharePoint — February 26, 2009 @ 6:50 pm
A bit late to the party, but I would have to add the way SPList.Items obscures the fact that it is not a simple property referencing some inner array – it does a query of ALL list items each time it’s used, as in myList.Items.Count or myList.Items.Add(newItem).

See http://mo.notono.us/2009_03_01_archive.html

Comment by Oskar Austegard — April 29, 2009 @ 1:05 pm
Oskar,

A bit late on your response but, while the methods you describe do a query of all list items, there is a better way to count the items in a SPList, try using myList.ItemCount, wich won’t have to query all the contents, there’s a way for adding an item without having the same effect but the workaround you have to make is so big, it’s not worth it most of the time (google ProcessBatchData).

Comment by Ricardo Irineo — September 14, 2009 @ 4:15 pm