Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6 - Part 7 - Part 8

OK, so there's plenty of hype at the moment for ASP.NET developers to "leverage the platform"...being SharePoint and a really flash (I mean silverlight) interface for them to click around on with the title "Do Less. Get More. Develop on SharePoint". This made me cringe after the last couple of weeks I've had on my current project and also with respect to these posts I've been putting up.

The site tries to push ten key aspects of SharePoint you get OOTB. Of which I have covered: Web Parts, Data Lists, Event Handlers and Custom Content Types already. I'll stress that I've only really scratched the surface on what these things can do, what I've shown you so far are the basics.

Now SharePoint isn't alone in this space...SharePoint sits on top of the .NET Framework, IIS and SQL much like other products out there. Some of which based on templates make it easy to generate database schemas, CRUD stored procedures, .NET DALs, .NET web services, ASP.NET presentation layers with a few clicks such as CodeSmith, MyGeneration, etc. Now granted you don't get User Management, Workflow engine...but you certainly can get Navigation and Page Branding with ASP.NET (although it has been extended with SharePoint).

Underpinning all of the ten really is the SharePoint Lists (SPList) at the core of:

1. Pages for navigation - yes pages are stored in a list
2. Web Parts - web parts are stored in a gallery that is a list
3. Event Handlers - not all event handlers hang off lists, but a lot of the reasons for using them would be
4. Workflow - see event handlers
5. Custom Content Types - the underlying List schemas

As an example of this OOTB platform I decided to use my new found love of Powershell to generate some sample data in my Schedule list I created in previous posts.

$weburl = "http://jt-asuslaptop/TestTVShowSchedule";

$web = global:Get-SPWeb($weburl, $null);

$list = $web.Lists["Schedule"];

$shows = "Heroes", "Underbelly", "Battlestar Gallactica", "Prison Break", "Lost", "House", "Greys Anatomy", "24", "Desperate Housewives" #one for the girls

for($s=0; $s -lt $shows.Count; $s++)

{ 

    $airdate = [datetime]'2008-1-1';

    for($se=0; $se -lt 6; $se++) #six seasons - yeah i know...who wants to see them escape from the prison or island again!

    { 

        for($e=0; $e -lt 24; $e++) #Jack Bauer is my hero!

        { 

            $spitem = $list.Items.Add() 

            $spitem["Title"] = $shows[$s];

            $spitem["Season_x0020_Number"] = $se;

            $spitem["Episode_x0020_Number"] = $e;

            $spitem["Air_x0020_Date"] = $airdate;

            $spitem.Update() 

            $airdate = $airdate.AddDays(7);

        }

    }

} 

Bearing in mind that this script will create 9 sets of 6 season 24 episode shows (1296 schedules)...now think about what I've hooked up here on an ItemAdded Event:

1. Create me a new page based on a given PageLayout
2. Add a Content By Query Web Part to the page and filter the schedules.

These base pages would allow Users to then add their own extra content about this show using Web Parts, comment on the show etc. etc. in a true Social Collaborative environment.

I ran this on my Windows 2003 laptop in a MOSS development environment with SQL 2005, Visual Studio 2005 and Microsoft Office 2007 (yes that's right I keep things simple on my personal PC using mainly web based tools).

The results...well all 1296 schedules were created in the list fine, all 1296 pages with a web part on them were also created...eventually after about 10 minutes of my PC at 100% processor.

"What's your point Jeremy?"

Well, I remember about four years ago working in a web shop with some excellent .NET developers and trying to introduce some new tools that would save us time. They all looked great when we ran prototypes with a few bits of data and a couple of developers hitting it. But when we released it...it ran like a dog and we ended up coding it how we normally did from the roots up to get better performance.

I don't think SharePoint is going to have that scary a story...but I think the way that Microsoft are currently trying to encourage .NET developers over to the SharePoint fold may be a bit premature as the ones that have already taken the punt and moved across are still hand cutting things and still finding out the intricacies and limits of the platform. It may have been a better idea to get the Developer tools up to speed first and solve the issues around Continuous Integration (Deployments, Builds, Unit Testing etc.) that .NET developers expect from a development platform.

I think Microsoft need to be clearer on where SharePoint is a good fit and where it clearly isn't. Don't give the Business another reason to ask why things are taking so long to develop now we have a platform that does it all for us and will "saves months of development time". I'll save the InfoPath vs. ASPX forms for another time.

Believe it or not, I am a SharePoint fan and I can see where they are coming from with the 10 things about SharePoint. As my series of posts has pointed out...it may look great in the interface to be able to create a List, add a Web Part...but when you want to start automating things or hooking in Workflow and Event Receivers you're on a completely other level.

STSDev and other tools have come a long way in the last few months in making our lives easier as SharePoint Developers. I'll continue on this series of posts to cover the 10 areas that the site has covered on the same theme...but sorry they'll be no sexy silverlight rollovers on my posts ;-)