I have to say SharePoint just continues to underwhelm me (as a developer, I don't mind the product itself I should probably make that clear)...

A couple of quick examples:

Configuration over Convention

Regional settings and dates are a prime example - for instance you get a which brings with it a common look and feel for date pickers in SharePoint... and on the various pre-canned forms etc. everything appears to display with the current user/sites regional settings.

However whenever you use this control you end up resorting to code along the lines of:

SPRegionalSettings regionalSettings = SPContext.Current.Web.CurrentUser.RegionalSettings ?? SPContext.Current.Web.RegionalSettings; myDatePickerControl.LocaleId = (int)regionalSettings.LocaleId;

Or extending your control yourself to do the same... why on earth would I not want the control to default to the current regional settings?

Again the lack of convention rears it's ugly head when working with SharePoint's SPGridView - if it's going to a render a date, why doesn't it render it with the current user's Locale in mind (which I've talked about in this  hack last year) - shouldn't these controls be taking that burden of responsibility away from me?

Useless Extensions Points

When something is extensible in SharePoint, then generally:

1. It's not documented (except by the community)
2. It doesn't really work for the most common scenario.

Take the  SPGridView and  SPDataSource combo - with this you can setup a grid to feed
from a CAML query pretty easily ... and it's smart enough to add the required to the underlying CAML query when you sort on a column... so far so good.

But what if you want to sort on more then one column?

Well, you could try specifying more then one column in the grid's SortExpression - but this causes the SPDataSource to spit the dummy... so obviously the first question is why doesn't that work, when it works for other data sources, and would have been trivial
to implement.

But not all hope is lost after opening reflector and perusing the code (which thankfully wasn't obfuscated in this case, though quite a bit of it is) you see that in fact you can specify additional sort columns in the original query and the SPDataSource is smart enough to keep them and insert the new field references into the existing ... a handy way for extending your query to have a number of default sort columns.

But there's a catch, it sticks the entries in the wrong position, so it will sort by the fixed columns first - rather then last - making it all but useless in most cases (users expect to click on a column and see the results sorted by the selected column first) .. And to be honest this still wouldn't worry me if I was given at least one virtual method to override allowing me to mutate the CAML query appropriately.