Another Argument for SharePoint Designer vs. Visual Studio
As anyone who follows my blog (or is unfortunate enough to get roped into a conversation with me about it) knows, I’m a HUGE fan of the Data View Web Part (aka Data Form Web Part or DVWP). Chris O’Brien has written two great posts (so far) about using just the SPDataSource to get at SharePoint-based content in your pages: SPDataSource – every SharePoint developer’s friend.
Most people I talk to find it hard to believe that I don’t want to write custom Web Parts to get things done, but with things like the SPDataSource available to you, you often just don’t need to go that far. SharePoint Designer may be just the ticket instead. Why is that important? Well, with various clients I have found:
- Deployment of managed code sometimes needs to go through a more rigorous (read: onerous, albeit perhaps necessary) process of QA, UAT, etc.
- Direct access to the server (or even Central Administration) may be off limits to you as a developer, especially in production
- So-called "custom" requirements may be needed on only one or two pages in the entire application
- Real codeheads (C# and/or VB) aren’t available in the SharePoint support group(s)
- Designer-based code can be stored and managed in a central location and reused in pages throughout the application
So, for any custom requirements that you find yourself faced with, try to seriously weigh whether you need to go to managed code or not. No, you can’t solve everything in SharePoint Designer, but if you can, with well-thought out processes it can make for easier deployment and application management.
