It happens with each new custom development I am involved with on the SharePoint platform - that initial temptation to write custom code, to head down the technical and complex route to a solution. Comes from having a background in software development, I guess!
The process of firing up Visual Studio and starting to code against the SharePoint APIs can thus become the "hammer" used to fix every "nail" (for "nail" read "business requirement").
But that is missing the point of SharePoint - there are plenty of built-in features that can greatly reduce the need for custom development. And hence reduce the cost to the client. Take one recent example from my work - a client required a web part that displayed documents created or modified by the current user, with some particular requirements around the way the metadata was displayed. Some of the functionality in this web part had me hovering the mouse over the Visual Studio start program link, but a little further design work revealed that the good ole' Data View (Data Form) web part could satisfy their needs.
The web part took around an hour to complete, with the necessary XSL jiggling. And one of the real benefits of taking this approach is the deployment - no WSP files to install on the server, no interruption to service. A simple text file to export and import.
Perhaps this is a paradox with SharePoint - as a development platform of significant breadth, it offers lots of different hammers for each nail. Me, I try (often have to remind myself!) to pick the lightest-weight hammer possible for each task. Lightweight = quicker development cycle = more agile and more responsive to customer requirements.
There is a proviso, of course (quite a major one) - the size of the client and their deployment/integration process may choose that hammer for you. The fast, lightweight approach that may be appropriate for clients with small, simple sites and a handful of users on a single server is unlikely to fit major organisations with strict control over the staging/QA/production environments. But even in that instance a Data View web part could be enveloped inside a SharePoint Feature and the deployment needs likely satisfied.
One step missing from the process when using this lightweight means of solving IT needs is the testing, or rather the inclusion of automated, repeateable testing. Someday I'll get a chance to look at the web test various frameworks around and to see whether NUnit combined with, say, WebAii or WATIN will help.
Subscribe to:
Post Comments (Atom)
2 comments:
There is a problem with some of the lightweight hammers - they are bigger than the VS Option. Adding a new list and view based upon a custom content type takes 3500 lines of xml (I am sure that this can be culled, but that is what the VS template produces) to do the same in code a takes less than 20 lines to do so generically. Sometimes VS.Net is the lighter hammer.
I agree with you entirely, Chris, about the huge "XML tax" levied on declarative definitions of the core elements in SharePoint - there's an awful lot of XML in the schema file for a list just to save a few simple records. It is a shame that so much repetitive markup is necessary to depict how each field is displayed in a view, for example.
However I do find I have become quite efficient in defining SharePoint artefacts through declaration rather than code, just from the fact of having done it lots! And declaration of some aspects is very terse and effective - for example, adding custom actions.
Coding (rather than declaring) the creation of these artefacts would allow much cleaner integration of testing into the development process. A test framework could run the "target" list creation code, then test the result of that code.
It is also possible, though not as clean, to programmatically deploy and activate SharePoint features (using a little reflection). I intend to blog about this technique sometime soon.
Post a Comment