Jan Tielens' Bloggings

Mister "SharePoint Administration" himself, Joel Oleson, has written a nice post about Site Collection sizing in SharePoint 2007.

Summary:

There is no hard limits post WSS 2.0 SP1/SP2. In WSS 2.0/SPS 2003 I recommend you pick a maximum site collection quota of no larger than 10GB where sites are in shared content databases or not the top level site collection.

In WSS 3.0/MOSS 2007 I recommend you pick a maximum site collection quota of no larger than 15GB, excluding the top level site collection and to move sites to dedicated databases where they need to grow beyond this.  SharePoint content databases can scale to hundreds of GB and SharePoint farms can handle TBs of content.  These recommendations are based on my experience with MS IT and in conversations with product support, and your experience may vary. full post here

[Via Angus Logan] Nintex, famous for their workflow solutions for SharePoint 2003, announced Nintex Workflow 2007. If the screenshots are for real: very impressive!

Every once in a while you bump into a new feature in the 2007 Microsoft Office System and you think "hey! this is really cool!". This happened to me last week when I was playing around with InfoPath 2007. To be able to share with you my little aha erlibnis (credit for this term goes to my former math teacher), let's assume you've got following InfoPath form: the U2U Course Order form. A very basic form with Customer, Email, Course and Date fields, and a repeating table with student name and email fields.

You probably know that if you publish an InfoPath form to a SharePoint document library (or content type), the Publishing Wizard will ask you which columns you would like to make available in the SharePoint document library. InfoPath will allow you to pick a field from your InfoPath form which will become a column in the document library, so the data of the filled out InfoPath form will be replicated in the document library automatically.

Let's select for example the Customer field, from the InfoPath fields list; the Column name will be filled out automatically. The new cool InfoPath/SharePoint 2007 feature is displayed at the bottom of the dialog window: "Allow users to edit data in this field by using a datasheet or properties page". If you select this checkbox, users will be able to edit the value of the Customer column in the SharePoint properties page (so without opening InfoPath), and that updated value will be stored in the InfoPath file! It's magic! :-) I repeated this step for Email and Course fields, and finished the Publishing Wizard. Then I filled out the InfoPath form in the InfoPath client application:

The filled out data is of course replicated in the columns of the SharePoint document library. Now let's click Edit Properties in the document's dropdown menu (aka ECB). 

Because I selected that the Customer, Email and Course fields could be edited in the properties page, you can change them and the values in the filled out InfoPath form (the XML file) are updated too!

ASP.NET AJAX has just RTM-ed, cool! Even cooler: Daniel Larson has released the SharePoint AJAX Toolkit on CodePlex, which uses the ASP.NET AJAX framework. This sounds very promising!

Daniel writes: ASP.NET Ajax Extensions (aka Atlas) have been released (finally!), and I've been saving up some code for the release which I'll post shortly. (Get eh 1.0 RTM bits here: ASP.NET 2.0 AJAX Extensions 1.0)The SharePoint Ajax Toolkit is also ready for release and is available as a WSP (SharePoint Solution Package) here with some nifty new features, including a Solution Package based installer that allows FULL no-touch deployment and registers the Atlas httpHandlers, as well as a Refresh interval programmed into the XmlWebPart (a great solution for SharePoint list RSS feeds). Included is one web part, the Xml Web Part (with a default RSS reader XSLT which can be set to auto refresh), and the core framework for AJAX developers. The source code is recommended for SharePoint developers.

Mmm, I guess my colleague Kevin (hey Kevin, when do you start a blog?), who is going to teach the first U2U ASP.NET AJAX training in two weeks, will have to give me an AJAX crash-course! :-)

[Via Bill Simser] Required for every SharePoint developer:

• SharePoint Server 2007 SDK
  The Microsoft Office SharePoint Server 2007 Software Development Kit (SDK) contains conceptual overviews, programming tasks, code samples, references, and an Enterprise Content Management (ECM) starter kit to guide you in developing solutions based on Microsoft Office SharePoint Server 2007.
• Windows SharePoint Services v3 SDK
  The Windows SharePoint Services 3.0 software development kit (SDK) contains conceptual overviews, programming tasks, samples, and references to guide you in developing solutions based on Microsoft Windows SharePoint Services 3.0.

Yes, that's right: the MOSS SDK includes the RTM version of the ECM Starter Kit!

Update: read the official SharePoint Team Blog announcement here!

[Via Thomas Hawk, Techcrunch] (Why do photo sharing sites need to have weird names: Flickr, SmugMug, Zooomr?) People who know me a little bit probably know that I love to take photographs, lots of photographs. My inner geek of course wants to do geeky stuff with all those pictures, so every picture gets: a) tagged and described (metadata stored in the picture itself so you never ever have to type descriptions, tags again) b) geo-tagged (store the coordinates where the picture was taken in the metadata) c) stored for eternity (I have a pro Flickr account, allowing unlimited upload and storage, it's my off-site backup). Why do I use Flickr, instead of other photo sharing/storing sites? Well when I started (a little over one year ago), Flickr was the only big one that exposed an API. So as a developer I could see my Flickr account as my "picture data store", accessible via a Services Interface; this means you are never "locked in", if a feature is not available you can write your own solution (eg batch download). Flickr has a very large community in general, but also a very large developer community: their API even has a .NET wrapper (kudos to the people who maintain this!) and the amount of tools is incredible.

A competitor of Flickr is SmugMug, they don't offer a free account (like Flickr does) but their feature set is richer. Things that I like about SmugMug, compared to Flickr: customizable home page layout ("web part" style), themes, hierarchical structure of albums (albums in albums, aka as sub-sets) and they use Google Maps instead of Yahoo Maps. I don't have a SmugMug account but I had a (free) trial account so I could play around with it. The price is right ($ 39.95 per year), but the main reason why I choose Flickr was their API and community.

Somewhere last year SmugMug however added their own API too, and this week they added some really cool features: speed, beauty and brains. The geeky translation for these features is: they switched from the "traditional" HTML user interface to an AJAX user interface. So no more page reloads, no more scrolling, better speed, nifty slide out effects and so on. Job well done SmugMug team! Don MacAskill (the SmugMug CEO and Chief Geek (I'd love to have geek on my business card!)) blogs about the latest release. He mentions the obvious advantages, but (more interesting) he also describes the less obvious pitfalls of this switch. Although these pitfalls apply to SmugMug, they could apply to all the sites switching from HTML to Ajax UI's.

• Search engines. I know Google’s been testing a more JavaScript-aware version of Googlebot, but how aware it really is is anyone’s guess. Certainly no crawlers I’m aware of do even a marginal job of crawling AJAX pages. But our customers spend tons of time captioning, describing, and keywording the 120+ million photos at SmugMug.
• Backwards compatibility. We built our URLs from day one to be “permalinks” so they wouldn’t change if you used them in your blog and forum posts. We had to make sure that things still worked going forward.
• AJAX Permalinks. Now we needed new permalinks that describe various pieces of data for browsing SmugMug, but we also needed to keep them short so people could copy & paste easily, so they wouldn’t wrap in emails, etc.
• Stats tracking. Specifically external sources like StatCounter and Google Analytics which only track page views, not JavaScript UI interactions. Our customers, especially the tens of thousands of hardworking Pros who build their photography businesses at SmugMug, expect to still get useful and meaningful statistics on who’s viewing what.
• Browser interfaces. People expect the Back & Forward buttons to work properly, along with History and Bookmarks. Doing so in all three major browsers was thought to be impossible, and we failed many times. We solved this one, and this was the last biggie. I believe it’s an internet first. Jimmy will be updating his blog about exactly how we do it so anyone else can follow suit. It’s good for the web as a whole for this stuff to move forward.

So I hope Flickr is going to follow the lead SmugMug has taken and add some of the fancy SmugMug features: their community is begging for them (Flickr is know to implement new features very, very slowly because they have to keep up with their ever growing user base and storage/performance requirements). Or maybe it's time to give SmugMug a chance, the only problem is that I will need to upload all my photo's (almost 10.000) once again... to be continued!

(It's all over the Belgian blogosphere, but I wanted to mention it as well!) If you want to see one of the "big shots" in the Microsoft .NET team, who happens to be an excellent speaker, you should come and visit the next VISUG meeting with Scott Guthrie! Visit the VISUG site for full details and registration (it's free!). Scott will present two sessions:

16.30-18.00: Session 1: First Look at Visual Studio and ASP.NET “Orcas”

This session will cover some of the great new features that will be coming soon with Visual Studio and ASP.NET “Orcas”.  Learn how web development with .NET will continue to improve and evolve, and talk about some of the upcoming features and how best to use them.

18:30 – 20:00: Session 2: ASP.NET 2.0 and ASP.NET AJAX Tips and Tricks

This session will provide some great tips and tricks on how to improve your web development today with ASP.NET 2.0, ASP.NET AJAX, and Visual Studio 2005.  It will cover VS project management recommendations, ASP.NET 2.0 UI techniques, ASP.NET AJAX suggestions, performance improvements, and deployment best practices.

Thanks to the VISUG team and MS Belux for organizing this, great job guys!

Recently I got a question from a student how to get a list of all the web parts (in code) that are displayed on a specific SharePoint Web Part Page. This could be useful if you would like to close all the web parts at once, add web parts programmatically etc. By using the SharePoint object model this is pretty easy, especially if you want to retrieve that list with code running in a web part. The WebPartManager property of the WebPart base class, gives you access to a collection of all the WebPartZones available on the page. Once you've got the zones, you can get the web part instances by using the WebParts property. The following web part code will display a small list of all the web parts found on the page, including the name of the web part class and the web parts zone.

using System;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using System.Web.UI.WebControls;

namespace WebPartLister
{
  public class WebPartLister : System.Web.UI.WebControls.WebParts.WebPart
  {
    BulletedList list;

    protected override void CreateChildControls()
    {
      list = new BulletedList();
      WebPartZoneCollection zones = this.WebPartManager.Zones;
      foreach (WebPartZone zone in zones)
      {
        WebPartCollection webparts = zone.WebParts;
        foreach (WebPart webpart in webparts)
        {
          list.Items.Add(
          string.Format("{0} ({1}), {2}",
            webpart.Title, webpart.GetType().Name,
            zone.DisplayTitle));
        }
      }
      this.Controls.Add(list);
    }

    protected override void Render(HtmlTextWriter writer)
    {
      EnsureChildControls();
      list.RenderControl(writer);
    }
  }
}

[Via Mark] Every SharePoint developer knows that creating SharePoint Solution Packages (WSP files) for deploying your web parts, event handlers, features, ... is the way to go: it allows the SharePoint administrators to easily deploy the customizations, even scheduled deployments and multi front-end-webserver deployments are supported. But every SharePoint developer also knows that creating Sharepoint Solutions Packages is ... wel, let's put it nicely: not a lot of fun to do. :-)

Vince Rothwell seems to have a very clean solution for this: a Visual Studio 2005 Template which generates a SharePoint Solution. Read the details in his blog post.

Today I got an interesting question in the U2U Sharepoint 2007 DevCamp in Copenhagen which I couldn't answer straight away (this happens more than I'd like it to happen). After some searching and with the help of one of the attendees we finally managed to answer the question!

In a Microsoft Office SharePoint Server (MOSS) 2007 Publishing Portal (aka Internet Facing Website, aka CMS vNext site) you can choose to schedule the publishing of pages. For example, suppose you would like to advertise a message on your site during a specified period of time (eg from the 25th of December to the 1st of January). This is possible because the underlying Page Publishing Content Type has the required fields (Scheduling Start Date and Scheduling End Date); the Page Layouts make use of this Content Type.

In a MOSS 2007 Collaboration Portal (aka Enterprise Portal, aka SPS vNext site) Page Layouts are used in the same way as in a Publishing Portal, so I supposed they would offer the same scheduled publication feature too. Wrong! Out-of-the-box publishing pages in Collaboration Portals can't be scheduled; the Publishing Console doesn't show this option:

My first guess was that the Page Layout for pages in Collaboration Portals didn't use the Content Type which included the Scheduling Start and End date, but wrong again; they do. It turned out that it's a setting on the document library itself (Manage Item Scheduling). To enable this functionality you need to follow these steps:

1. Navigate to the Document Library Settings page of the Pages document library. You can find the Pages document library by clicking the View All Site Content link on top of the Quick Launch.
   
   
2. Click the Versioning Settings link and enable content approval, verify as well that both major and draft versions are allowed.
   
   
3. Click OK and so you'll end up back on the Settings page of the document library. Now click the Manage Item Scheduling link.
   
   
4. Check the Enable scheduling of items in this list option and click OK. Voila, now you will be able to schedule the publication of pages in this document library!
   
   

To actually schedule a page to be published in a specific timeframe, create a new page in the modified Pages document library (or edit an existing one). The Publishing Console will show the Publication Start Date.

If you click the Immediately link, you can enter the schedule: