Whilst SharePoint is one of Microsoft’s fastest growing products, it’s also one of the most frustrating to develop for. Recently I’ve been been doing some WSS and MOSS site customisations with SharePoint Designer and custom Web Controls. To me this is the type of development that most people will be doing. Most ISVs are doing back end work, further from the realm of the consultant or business developer. Microsoft seems to cater more to the latter group.
Some of my gripes include:
- The theme system being tied to the HTML split between Master Pages and WebParts. It would nice to be able to easily customise the HTML that is generated.
- SharePoint Designer marks files as dirty when they are opened. What is being modified? Occurs most frequently when I’m working with Master Pages.
- Superfluous XSLT generation when a ListViewWebPart is turned into an XSL Data View. Why include templates that are not used? Why not offer to store the XSLT in separate files for easier management. There are cases where the XSLT code generated in invalid too (bad code in conditional tests).
- Moving XSL code to separate files introduces another problem with dirty files. Saving Master Pages that reference external XSLT files can result in a dialog that asks whether to overwrite. I’ve found that I should always accept the offer to overwrite
I’m pretty sure these issues are easy to fix, but Microsoft and other SharePoint developers recommend that development is done with the ISV-oriented tools. This is very inconvenient since the product is sold as a rapid development platform and packaging/deployment requires quite a bit of extra effort to get right. Hopefully the SharePoint experience will improve for front end developers in the next release.
Brian Lyttle runs Source Foundry, a consultancy
that specialises in Web development and content management. When he's not writing code and experimenting with
the latest tools, you can find him honing his 