23 February, 2006

SharePoint list: Group by month

If you have a SharePoint list that contains a date column, you may want to create a view that groups all the items by month. For example, in a standard task list you can create a view that groups the tasks by which month the Due Date is in.

To accomplish this, create a calculated field that returns a single line of text and has the following formula:

=YEAR([Due Date])&"-"&CHOOSE(MONTH(DATEVALUE("1/"&MONTH([Due Date])&"/"&YEAR([Due Date]))),"01. January","02. February","03. March","04. April","05. May","06. June","07. July","08. August","09. September","10. October","11. November","12. December")

Then select this field under Group By when customising your view. It can also be used for filtering and a similar calculated field can be used to group by week or by year.

Thanks to Ivan Wilson's post, I realised I don't need an unmanageable long nested if-statement to accomplish this. The CHOOSE function is very useful.

Stay tuned to my SharePoint musings: Subscribe via email or RSS.

21 February, 2006

UI Customisation in SharePoint 2007

In the current version of SharePoint, advanced customisation of the look and feel can easily be a very complicated task. With smaller deployments you can often get away with using the power of FrontPage 2003. However, when it comes to larger deployments with hundreds of team sites and/or portal areas, you face some real challenges. There are basically two different ways of approaching this. Either you go down the track of custom templates or the track of site definitions.

The custom templates are the ones you create by customising a site through the UI and then saving it as a template. This is straight forward to do, but the biggest drawback is that sites created from custom templates have no link to the template once they have been created. As a consequence, you cannot modify existing sites by making changes to the template.

Site defitions, which are sitting on the file system of the front-end web servers, solves the problem of being able to make changes that affect all existing sites. The trade off with site definitions though is that they are complex and time consuming to build. It requires lots of CAML editing and even simple layout changes have to be carried out in potentially hundreds of different HTML files. The site definition for the default team site contains 97 HTML pages with lots of duplicated HTML across most of the files.

The next version of SharePoint, which is included in the 2007 Microsoft Office release towards the end of this year, will be build on ASP.NET 2.0 master pages. This fact alone will ease customisation substantially. The master page will typically contain the branding, header, footer and navigation for the site. You will be able to redesign an entire family of sites, by modifying the master page.

Apart from master pages, SharePoint 2007 will have other improvements that will ease customisation of the look and feel. These include new and improved web parts and web part zones as well as the page layouts adopted from MCMS 2002. The SharePoint Team Blog has a good post on how the new SharePoint pages will be composed. The upshot is that it will become more realistic to train up creative designers to build SharePoint layouts and I believe we will see some very sexy SharePoint implementations in the future.

19 February, 2006

Office SharePoint Server 2007

With a press release last week, Microsoft presented the official names for the Office 12 suite of products. As expected, this includes Office SharePoint Server 2007 which merges SPS and MCMS together and the new Office SharePoint Designer 2007 which is partially based on FrontPage 2003. All the products are expected to be available by the end of 2006.

Dustin Miller has a comprehensive list of features in Office SharePoint Server 2007. Each feature has a link to more details on a blog, in a slide show or on a Channel 9 video.

14 February, 2006

Storing documents in the database versus on the file sytem

The long-term strategy for storage technology at Microsoft is to take advantage of SQL Server relational database technology wherever possible, and SharePoint Products and Technologies is a showcase example. In SharePoint, all content including BLOBs (Office docs, images, etc.) and configuration information is stored in SQL databases.

Recently, I have come across a number of DBAs that religiously refuse to have any BLOBs stored in their databases. This obviously limits how custom applications handling images and other documents can be designed. In addition, Windows SharePoint Services is not a popular technology with those DBAs.

There are a number of significant benefits of having your BLOBs stored in the database. First of all, you gain all the ACID properties of your transactions. Trying to obtain that in an architecture with data in the database and BLOBs on the file system is certainly not a trivial challenge. Secondly, BLOB data is backed up with the database easing administration. Another benefit is that SQL Server Full Text Search operations can be performed against formatted text-based data contained within BLOBs (eg. Word docs, PDF docs, etc.).

SharePoint takes fully advantage of all these benefits. The benefits do however come with a cost. Because SQL Server breaks BLOBs up into chunks that fit on database pages, there is a performance overhead when reassembling the BLOBs on retrieval compared to if they were stored on a file system.

In summary, there is no one right answer to where you should store your BLOBs. It all depends on the context. You need to consider the performance issues in the database and hold them up against the benefits of having your BLOBs stored in the database. A good example of resources that are better stored on the file system rather than in the database is images that are typically referenced via HTTP HREF.

For SharePoint, where BLOBs (mainly Office docs) are not extraordinary large files, the benefits definitely outweighs the slight performance overhead. Images that are referenced from within the HTML in the SharePoint site definitions are stored on the file system. These scnerios are good to keep in mind when considering BLOB storage strategy for your own custom applications.

07 February, 2006

BSPUG: Creating SharePoint Site Definitions

In my presentation today at the Brisbane SharePoint User Group, I gave an introduction into what is involved in creating and using SharePoint site definitions. As promised, here's a list of references that relate to what was covered.

  • MSDN gives a good introduction to site definitions and custom templates including pros and cons with the two approaches.

  • Heather Solomon gives a comprehensive walkthrough of how to create a site definition including how to create a list template.

  • MSDN has an introduction to CAML followed by a complete reference on all the elements and attributes.

  • Todd Bleeker has a post on how to use the AlternateCSS attribute in CAML to apply a custom style sheet to a site definition.

Thanks to James Milne for an excellent presentation on customising SharePoint forms with FrontPage. Drop by his website and check out his great tools including the SharePoint Style Designer he showed us briefly today.

02 February, 2006

Preview of InfoPath 12

A member of the InfoPath 12 development team at Microsoft, Tudor Toma, has started a blog about the new features of the product. His first post gives an overview of the browser-based InfoPath forms including support for mobile devices.

The browser-based forms should eliminate the need for having the InfoPath Windows client rolled out to every single user which is often a strong argument against leveraging InfoPath for electronic forms.