After a couple of weeks on holiday, I am back into it... and I thought I would get started with a post on the way I customise a SharePoint project. This post  won't cover coding or how to configure sites, but more of the philosophy behind the customisation of a deployment.

When I get a new project to sink my teeth into I generally split the customisation into three parts: Configuration, SharePoint Designer and Custom Coding.

The three phases

As I explained above, I use three phases when I do any customisation in SharePoint. Some projects may only need to use the first, some may need all three. Below is an explanation of each of those phases:

Configuration

Using SharePoint's out-of-the-box functionality you should be able to achieve between 60%-80% of the required customisation (or 100% if it is a less complicated project).

Using Sites, Lists, Content Types, etc. you should be able to get a working example of a site. Usually this can be done with the users to ensure your requirements are correct and saves re-work later on.

I also find starting the build like this, you can let the project team loose on the site and as they get a feel for it they may move the requirements... it is better it happens at this stage, rather than on delivery when a lot more work has been done to the solution.

Once the initial configuration has been completed and a gap analysis has been done to determine what (if any) further customisation needs to be done you will need to crack open either SharePoint Designer (SPD) or Visual Studio (VS).

SharePoint Designer

The next phase of any custom work I do requires SharePoint Designer (SPD). SPD is a tool that doesn't require masses of coding (VB.NET or C#) knowledge and can be used by technical BA's or skilled up power users. This doesn't mean developers can't use it as well!

I generally use SharePoint designer to:

• Change the look and feel for the site
• Display Cross-Site information in the Data View Web Part
• Use SP Data source controls to populate ASPX controls
• Do basic customisation of list views using the Custom List Form Web Part
• Create basic workflows
• Generally messing with the SharePoint Pages

Most of the time SharePoint Designer will get you close to the finish line. There are a few issues with it (not being able to easily move Workflows is one of them), but the good out-weights the bad!

Custom Coding (Visual Studio)

The third and final phase in any custom work is the cutting of custom code. The tool I use when customising a project in this way is Visual Studio. This is the realm of the developer and comes with all of the "extras" that go with full custom development (support, bugs, upgrade changes, etc.). But, VS allows you to really make the final changes to customise the project to 100% of the users requirements.

I use VSeWSS and other tools along with VS to do the following tweaks:

• Create full site definitions so re-deploying the same site template is easy!
• Create state machine and complex sequential workflows
• Create custom Web Parts to modify and display information
• Write event handlers to catch and process requests

and the list can go on and on... Where there are any gaps left after the first two steps, it should be cleaned up with code.

What to use and When

The size of the project generally dictates how far down the list you will need to go to get the solution you want. Below is a table that shows where you which direction you need to head:

Conclusion

Hopefully the above information will prove useful when deciding what path to take with customisation of your SharePoint project. If you have a large project that requires a fair bit of custom work, try and get the most out of SharePoint before you start using SharePoint Designer or Visual Studio... it is amazing what a little bit of planning and architecture can do! Anywhere from 60% - 80% of a large project can be completed without even opening SPD or VS.

I am presenting at this months Bay of Plenty SharePoint User Group... The topic is: SharePoint Workflows from a Developers Point-of-View.

Here is a blurb about the presentation:

Workflows can be a powerful tool for an organisation to automate many processes and decrease information duplication and becoming misplaced. In this session Eamon will create a workflow using Visual Studio to show the power of SharePoint’s Workflow Engine working with enterprise line-of-business applications. This session is aimed at developers, but it may be useful for power users to get a look at what is possible with customised workflows.

I will record the session and post it on here, so anyone that misses it will be able to watch it and post questions.

Over the past couple of days I have been playing with an internal project, so I thought I would play and query the lists with LINQ... here is what I came up with!

Because a SPListItemCollection inherits from ICollection, we can attack it with a LINQ query... and that we shall!

A bit of background, I am using a Web Part to render the information to the user. The Web Part has a several properties for the user to supply information to configure it (they will appear in the "Miscellaneous" section of the Web Part Properties Pane). The properties are as follows, the CAML property is optional, but it gives an easy way to filter information from the list without going into the code:

   1: Private _siteurl As String = ""

   2: <WebBrowsable(True), _

   3: WebDisplayName("Web Site URL *"), _

   4: WebDescription("The site the list is located."), _

   5: Personalizable(PersonalizationScope.User)> _

   6: Public Property SiteURL() As String

   7:     Get

   8:         Return Me._siteurl

   9:     End Get

  10:     Set(ByVal value As String)

  11:         Me._siteurl = value

  12:     End Set

  13: End Property

  14:  

  15: Private _listGuid As String = ""

  16: <WebBrowsable(True), _

  17: WebDisplayName("Test Management List GUID *"), _

  18: WebDescription("Enter the GUID for the List."), _

  19: Personalizable(PersonalizationScope.User)> _

  20: Public Property ListGUID() As String

  21:     Get

  22:         Return Me._listGuid

  23:     End Get

  24:     Set(ByVal value As String)

  25:         Me._listGuid = value

  26:     End Set

  27: End Property

  28:  

  29: Private _camlQuery As String = ""

  30: <WebBrowsable(True), _

  31: WebDisplayName("CAML query for the webpart"), _

  32: WebDescription("Enter the CAML for the List."), _

  33: Personalizable(PersonalizationScope.User)> _

  34: Public Property CAML() As String

  35:     Get

  36:         Return Me._camlQuery

  37:     End Get

  38:     Set(ByVal value As String)

  39:         Me._camlQuery = value

  40:     End Set

  41: End Property

The first thing we need to do in the process is attach to the site and then web that we want we want to query. To do this I do the following:

   1: ' Create a Web object to use through the routine

   2: Dim Web as SPWeb

   3: ' Crate a local SPWeb Object

   4: Dim _thisweb As SPWeb

   5: ' Open the site with the URL supplied by the user

   6: Dim SiteColl As SPSite = New SPSite(SiteURL)

   7: _thisweb = SiteColl.OpenWeb

   8: ' Write the SPWeb Object to the property

   9: Web = _thisweb

  10: ' Clean up the SPWeb Object

  11: _thisweb.Dispose()

  12: _thisweb.Close()

This gives us an SPWeb object to play with. In the next snippet of code we attach to the list and create a CAML query object (SPQuery) that we will apply if it was supplied:

   1: ' Attach to the list

   2: Dim thisListGUID As Guid = New Guid(_listGuid)

   3: Dim list As SPList = Web.Lists(thisListGUID)

   4:  

   5: ' Define the Query

   6: Dim query As SPQuery = New SPQuery(list.DefaultView)

   7: If CAML <> "" Then

   8:     query.Query = CAML

   9: End If

Now we have all of that set up, we can make the LINQ query. in this query we are simply retrieving the data, but it is possible to sort, group by etc. as well.

   1: Dim linqQuery = From Z As SPListItem In list.GetItems(query) _

   2:                                   Select Z

Now we have the information, we can loop through it and do what we want with it. Below I have shown we can use a Lambda Query to group SharePoint information. In the example list I have Title, Category and Status fields and I want to group the information by the Category and then do something depending on the status, it may be some conditional formatting depending on other properties or maybe assign a task... anything really.

The reason for the substring is that SharePoint formats fields with an ID and then the Human Readable value, e.g. 1;#Status. We only want what is after the #.

   1: Dim CategoryTitle as String = ""

   2: For Each i In linqQuery.GroupBy(Function(a As SPListItem) a("Category"))

   3:     CategoryTitle = i.Key.ToString.Substring(i.Key.ToString.LastIndexOf("#") + 1)

   4:     For Each item In i

   5:         Select Case item("Status").ToString

   6:             Case "Open"

   7:                 ' Do Something

   8:             Case "Closed"

   9:                 ' Do Something

  10:             Case Else

  11:                 ' Do Something else

  12:         End Select

  13:     Next

  14: Next 

Hopefully that is a fairly quick and easy demo of how to get information from SharePoint as objects and use them!

It seems every time I talk to another developer about SharePoint, the second I mention SharePoint Designer (SPD) I get a sideways look and told "I won't use FrontPage". First off, Expression blend is FrontPage; SharePoint Designer is a tool to modify and enhance SharePoint. Hopefully reading the rest of this post will motivate you to install it (or open it) and give it a good ole' fashion thrashing... not too hard, it has a tenancy to break every now and then...

The list below isn't wholly features of SPD, it includes spin-offs that have come in handy for myself and others using it.

I have ordered this list from what I think are its great features, to the best features... in terms of how it helps me when tinkering with SharePoint.

1. Let Technical BA's and Power Users do their stuff

I wasn't sure whether to put this in the number one position or ten, but it made it to one... I am developer, I enjoy chunking through code and not doing workflow and page modifications that don't include at least one line of VB. Getting a technical analyst trained up in SPD will save a lot of time for everyone. For example, say a client asks for modifications in a workshop, the analyst can do these on the fly, fantastic! This tool is aimed at those sort of power users, so let them go for it!

2. The DataView Web Part

This is my favourite feature of SPD. It takes all of two minutes to get a DataView Web Part on your page and linked up to a data source. Creating custom views and filtering information from around the site is simple using this feature. If a project manager has ever asked you to give them a summary of all their outstanding tasks across all their projects, then the DataView Web Part will help a lot!

Dataview Web Parts use XSLT to render the data. Looking back at point one, there are some things BA's can't do, one of those is tweaking the XSLT... the DataView Web Part offers an extension (ddwrt namespace) that helps a bit, but there is always something that will need some customisation.

3. ASPX Page Editing

Have you ever tried to edit SharePoint ASPX pages in Visual Studio? If you need to make changes to the look and feel of a page, then SPD is the only tool to use. If you are creating a feature, you wouldn't use SPD to create the sites/lists etc. but to modify existing pages, SPD is great! Another advantage of SPD over Visual Studio is the preview... Visual Studio doesn't give you a preview of the page when it is up on the site, SPD does. In saying that, you can copy the ASPX code from VS and paste it into SPD to see how it looks.

4. Branding SharePoint Sites

This isn't a feature as such, but it is something that is near impossible without SPD. Modifying your "companyPage.master" is simple in SPD, it gives you a great preview, all the controls SharePoint controls in a menu (see image) ready to drag on and use.

Editing your corporate style sheet and seeing the results straight away is another bonus of SPD. Doing it the hard way would mean changing it in an editor of choice, uploading it to the 12 hive, refreshing the APP pool and then the browser... SPD seems a lot easier!

5. Workflow Designer

As I said in point one, getting some of the workflows completed by a BA will help the progress of the project to no end. Of course, there are limitations to the sort of things the SPD workflow designer can do, anything that needs some custom coding will have to go to the developers. All in all the workflow designer in SPD is a great tool for getting a workflow out and working!

6. SP Datasource

Out of the top five, but only just! This is an easy way to connect to any number of data sources, not just SharePoint.

A few Examples:

• SharePoint Lists
• SharePoint Libraries
• Other Databases
• XML Files
• Linked sources
• BDC (If you are running the enterprise version of MOSS,
  see my post on the differences between WSS and MOSS for details)
• Web Services (SharePoint or Other), see the image for an example of output data

One of the really cool data sources is the Linked sources data source. The can pull together any number of other data sources and give you a sing source, great for roll ups from multiple sites.

SP Datasource can be used by a DataView Web Part OR be dragged onto your page as a normal ASP.NET data source and consumed by any of the standard ASP.NET controls. For example, if you wanted a drop-down list that looks to an active issues list: connect to that list, filter the list showing only active and drag the data source onto the page, that easy!

7. Custom List Forms

Much like the SP Datasource, this is something that is a must for anyone checking out SPD to have a look at. If you want to customise any list, survey, etc. within SharePoint, you will need to use this feature. This is a great thing if you want to add some additional information to a list form, change the way titles are displayed, or generally mess with a form.

8. Site Connectivity

Using SPD to connect to a SharePoint site opens up a whole bunch of interesting places you wouldn't have known about unless you went for a hunt through the database and 12 hive. Opening a site in SPD shows all the master page and css files that give the site its look and feel (see the image to the left). You can view all the sites and lists within the folder list.

9. Client Application

The fact that SPD is a client application that can connect to SharePoint is great! There is no need to install a virtual server to do development work, it sits on a normal PC and connects to the deployment without issue.

10. Import/Export

And finally in the tenth position the ability to export and import sites to either a SharePoint site template or a Personal Web Package. Makes it very easy to move something from a development environment to testing, without having to create a whole bunch of XML and config files. This feature is great for moving something like a Wiki from one site to another, without losing the links!

Hopefully that gives you enough to break out the Office disk and put SharePoint Designer on your machine! If you have any comments or other reasons why SharePoint Designer is a cool product, please submit a comment!

I had to go through the process of installing a new virtual machine for SharePoint development today and realised there was a fair list of tools that I use in SharePoint Development.

As SharePoint is (in my view) an extension of the .NET framework, and as such a platform for developers to weave their magic, some of the tools in my list are tools I also use in my general ASP.NET development. So without further ado, my list of development tools (this list will change from time to time!):