Regarding MOSS or WSS 3.0, What parts of the API might have been implemented better?

Question

Such as:

• Sealed Methods you might have liked to extend
• Exceptions thrown are more vague than is helpful
• Elimination of Connected Content which was a major feature in MCMS 2002
• HTML is stripped from fields when stored and returned. No easy option to work around this problem
• Creating an SPWeb takes an eternity.
• Nonexistant migration path from MCMC 2002

Panzer

Touche! How do you really feel about it? – Panzer

I agree with Rex. ;) The API is monstrous. Has anyone else seen memory leaks starting workflows in code? – Fitzsimmons

Hopefully the amount of sales ($) generated by MOSS will enable them to revisit the internals of the OM. I fear though that, that exact reason will prevent them as they'll want to maintain backwards compatibility. – Fatimafatimah

This should be community wiki. Good question by the way. – Vigorous

Oh and you might want to make your answers actual answers... – Vigorous

Answer 1

I wish that the Sharepoint object model was purely managed code. Although having .NET wrappers is convenient, having to worry about disposing the many objects that implement IDisposable is a pain. It's so easy to run into memory issues when dispose does not get called in a WSS app. And I thought the reason for moving to .NET was to free developers from having to deal with memory management...

Accouterment

+1 you should see some of the patterns we've come up with for ensuring we properly dispose every SPWeb in a branching recursion – Isoagglutination

I agree here too. SPWeb is a nightware to keep under control. – Fitzsimmons

Answer 2

How about refactoring Properties that result in additional database calls to methods instead, for example the Items property on SPList.

Fatimafatimah

Answer 3

Any of the SPList API could use a complete rewrite. Trying to deal with libraries with nested folders is a complete nightmare with the list being completely flattened with no obvious hierarchical structure.

Another wonderful addition would be adding interfaces to SPWeb, SPList and other Sharepoint classes to aid testing.

Fitzsimmons

Answer 4

Has anyone seen this method: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx This method shows the unbelievable nonsense that Sharepoint exposes to developers.

Fitzsimmons

It would be great to see more details as to how you've seen it misused :) – Vigorous

Answer 5

My personal favourite is the SPField.GetFieldValue Method. I have no idea why they designed it the way they did, but to me it does hardly make sense. To get a object out of a ListItem you have to do somethine like:

SPField field = ((SPList)list).Fields.GetField("FieldName"); 
object fieldValue = field.GetFieldValue(((SPListItem)item)[field.Title].ToString());

Getting an object out of a ListItem is IMO a basic operation, so this should not be that complicated.

Lennielenno

Answer 6

Inconsistencies when passing field names to methods or arrays. For example:

• SPFieldCollection.ContainsField(): Internal name or display name
• SPFieldCollection.GetField(): Internal name or display name
• SPFieldCollection.GetFieldByInternalName(): Internal name
• SPFieldCollection.Item: Display name
• SPListItem.Item: Internal name or display name
• SPListItem.GetFormattedValue(): Internal name or display name
• SPViewFieldCollection.Exists: Internal name

To put the icing on the cake, there is usually no documentation about whether a method takes internal and/or display name.

Vigorous