10 development-related things I’d love to see in SharePoint vNext

In my previous post I’ve shared with you 5 experience-related things I’d love to see in SharePoint vNext. Now it’s time for Part #2: Development – the things I deal with every day.

Less internal code

The object model of both WSS 3.0 and MOSS 2007 is very powerful. It allows us – developers to do cool things with SharePoint and build some great solutions on top of it. While the solutions you could build are virtually unlimited, their viability and scalability isn’t. At the end of the day we will either have to use the standard functionality or write some custom code. And when that part comes we will have to communicate with SharePoint using its API. The only condition to do that is that SharePoint allows us to. The classes we want to communicate with, the methods we want to use and the properties we want to access must be public if we – developers want to use them in our solutions. And the more functionality there is available the better and more robust solutions we can build. So why both WSS and MOSS teams have shipped us code with some hidden gems that could save us hours of development time?

A piece of Variation Labels page in Microsoft Office SharePoint Server 2007 Variations in SharePoint are just one example of internal API shipped with SharePoint. How are we supposed to automate deployment of a multilingual Web Content Management (WCM) solution if the only way to create Variation Hierarchies is to click a button?

So for the SharePoint vNext I really hope both WSS and MOSS team will unveil all the hidden gems included in the object model and document it well enough so that we will be able to write code on top of SharePoint even easier, focusing on the solution and requirements. I hope there will be no internally scoped code anymore and we will be provided more access to the SharePoint framework.

Less hidden stuff

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair

  • Douglas Adams, Hitchhikers Guide to the Galaxy

SharePoint is a pretty complex platform. It has very rich functionality which can be tweaked by power users and developers to build great solutions. In order to support that amount of flexibility it has to rely on many variables. As you might’ve guessed, both the WSS and the MOSS team wanted to simplify working with and configuring all these different settings. Instead they hid the configuration and presented us some simplified interface.

The first problem arises when you want to script configuring all these settings. Where are you supposed to look and for what? Because the interface provides an abstraction layer to the object model there is not always a direct relationship between the settings and properties of the classes we know from the SharePoint SDK. At the end of the day it all makes understanding how SharePoint works difficult.

The second problem is, that when things go wrong, there is virtually no way you can fix it. Because you cannot access any of the hidden settings in a straight-forward manner you either have to dive into the hidden objects or just start all over again hoping you won’t make the same mistake twice.

I absolutely agree that the end-users shouldn’t be presented with too many options. Providing them as simple interface possible so that they can do their job, will make them work more efficient. But why would you hide things from developers who are supposed to extend the platform with some custom functionality? Why wouldn’t we instead get a possibility to hide things from the end-users and keep all the access for ourselves: a bit like the ViewFormLockDown Feature but then for all the hidden lists, configurations, etc.

Make it all less fragile

There are things in SharePoint which you could virtually slam with a hammer and they would keep working. If something goes wrong with a list item or a site, you could just delete it and create it again. In case of a site it might take a while to configure, but still the damage would be limited to that particular site only. But have you ever worked with Variations for example?

This particular piece of SharePoint seems really really fragile to me. While configuring it is pretty straight-forward, the moment you start creating hierarchies and creating items within the Source Variation, many weird things start to happen. It all starts with running a job so that every site within the Variation root gets an equivalent in all other variations. The job does a lot of work in the background, and sets some hidden/internal properties which determine whether the variation for the particular site has been properly created or not. I’ve ended up way too many times, with either a some sort of COMException or an error saying that no variations can be made because the site doesn’t exist within a Variation Hierarchy, to use variations with confidence. Isn’t there a more robust model to support multiple languages in SharePoint?

This leads us to another thing I’d love to see in SharePoint vNext:

Give us more feedback

How many times did you end up with a not much saying error message like ‘Unexpected error’ or a COMException? Most of the time you would eventually succeed to find the reason by viewing page source, looking into the SharePoint logs and/or following the Event Viewer messages. If the error message is being logged in one place or the other: why not display it on the screen as well? I’m pretty sure that it would decrease the overall development time.

Additionally: why not provide us a kind of ‘SharePoint Reflector’ application which would help us discover what exactly is happening behind the scenes? I’m quite convinced that giving us the ability to monitor requests fired towards SharePoint and generated responses on all layers would not only save us time but improve error reporting towards Microsoft and simplify error solving as well. Wrapping it all in one single place would give us a really powerful tool which would improve the SharePoint debugging experience. Furthermore, by understanding how SharePoint works, we would become better developers and would be able to leverage the platform instead of misusing it by demanding of it things, it wasn’t meant to do.

Development mode: On

Wouldn’t it be great to be able to enable all the development-mode-settings with one mouse-click? And then, just before passing the solution off to the users for testing, turn it all off – with just one mouse-click again?

More than a year ago Ted Pattison has created the SharePoint Debugger Feature which updates web.config to enable debugging. It would be great to make this a part of SharePoint and extend it leveraging all the internal mechanisms which are in general hidden from the developers. The easier it is to toggle the development settings, the more reliable solutions we can build and the less risk there is of ‘forgetting’ to turn something off before moving to the production environment.

Documenting the configuration

Creating SharePoint solutions means not only developing custom code but also reusing the standard functionality. Most of the time it comes down to configuring existing assets and dropping web parts on pages. How would you document all the different things you have to set within SharePoint? Do you include the configuration overview in either Functional or Tech Specs or do you have another document to store the configuration in?

I consider myself a developer and in general developers don’t like to write long documents. If I was given a choice I wouldn’t do it either. Personally I would love it if there was a mechanism in SharePoint to configure all the different settings, hit a button and then get it all in XML so that using XSLT we could: a) generate configuration documentation, b) automatically provision the required configuration without having to click the things again.

Content Types versioning

If you’ve worked with Content Types in SharePoint you’ve probably noticed the Version attribute on the ContentType element. According to the MSDN documentation it’s reserved for future use. Guess what? The future is now. How about we actually benefit of that extra piece of information?

Versioning Content Types is an important aspect of all Content Management solutions. It allows you to manage the structure of the information and its meta data. Right now the only thing you could do in case of a Content Type change is to programmatically update the Content Type information and migrate the data to reflect the changes. Doesn’t sound pretty reliable, does it? It would be great if SharePoint vNext allowed us to approach this challenge in a more structured and repeatable manner.

Versioning anything else…

Content Types are not the only area in SharePoint that the idea versioning applies to. Features and Solutions are two more examples I would love to be able to version. Just like it is possible to provide versions to Windows Applications which allow you to update the app, it would be great to be able to do the same with Features and Solutions.

Separate configuration from code

SharePoint doesn’t provide any mechanism for structured and repeatable deployment of solution configuration. While Solutions and Features work pretty well for deploying assets, there is nothing that would help us to provision all the different configuration settings that make part of the solution. One of the mechanisms which are often being “misused” to provision the configuration are Feature Receivers. I admit: they do the job, but is it really wise to put all your configuration settings in custom code? And then: will you put all the different settings in one Feature or create different Features to configure different settings? And what about keeping the overview of what you’re provisioning?

Surprisingly there is one place in SharePoint which allows you to deploy bits of configuration in a neat way. I’m talking here about the PortalProvisioningProvider. Using an XML file as input the PortalProvisioningProvider can create a whole hierarchy of SPWebs. But why is it limited to create only sites? Why can’t we use it to provision sites, lists, pages and set properties of all these objects?

Separating the configuration from code would improve the manageability of SharePoint solutions. By slightly modifying a couple of settings you could easily deploy a whole new solution. Sounds great, doesn’t it?

Use more XML/XSLT for data presentation

There are quite a few controls in SharePoint that use XML/XSLT for data presentation among which Search Results, Content Query Web Part and List View Web Part. In my opinion more/all controls should produce XML output and use XSLT to format it.

The XML/XSLT combination means lots and lots of flexibility. Because using XSLT you can transform the XML to anything you want, you are able to create as complex and interactive user experience as you want. On the other hand, because you are fully in control of what HTML is being produced, you could make accessible sites without any hacks whatsoever.

It would be great if SharePoint vNext used XML/XSLT in many more places. In most situations it’s not the common Web Parts that are causing the troubles. Quite often we need some more control over the markup of menus and maybe even complete pages (<html>…</html>).

SharePoint 2007 isn’t an intranet-only platform anymore. The Publishing Features of MOSS 2007 provide a framework to build Internet-facing sites. Web development however is way different than writing intranet applications. Developing for the Web means designing according to the existing web standards and developing for many different platforms. The only way to achieve the desired results is to allow the developers/designers to fully control what’s being sent to the output. XML/XSLT provide such flexibility: just look at ARF by Vincent Rothwell. It not only gives you great flexibility but helps you speed up development as well. It would be really cool if SharePoint vNext relied more on XML/XSLT for the user experience.

Wrap up

Developing SharePoint solutions isn’t as straight-forward as we would like it to be. There are many different things to consider while designing solutions and writing the code. I really hope that SharePoint vNext will simplify the development process and allow us to focus on the solution itself instead of all the framework-related things we have to think about at the moment.

In the next post of the n things I’d love to see in SharePoint vNext series I will talk about Web Content Management. Stay tuned!

Technorati Tags: SharePoint, SharePoint 2007, WSS 3.0, MOSS 2007


comments powered by Disqus