Click Mice, Unclick Mice

This is a really long post, so for those of you that are impatient you can find the finished product here.

Making it Happen

Since we are doing this with the mantra of no custom code, that gives me two choices for how to make this happen: the List View web part and Data View web part.  List View is too restrictive so I am going to punt on that and we'll do this as a Data View.

Section 1 - Configure And Convert A List View

The first step is to load up the site in SharePoint Designer.  It happens to be my favorite editor for this kind of thing, and so that is what I'll be using.  Now once Designer is open, I am going to add a Posts list view web part.  I can feel you scratching your head, wondering if I remember that about a paragraph ago I was going to use a Data View.  I am, but the SharePoint Designer team has done a lot for me already in terms the #4 requirement on the theme.  If I convert the List View web part to a Data View, it will keep the CSS settings of the List View.  On the other hand, if I start from a fresh Data View I have to go through and setup the proper table and CSS structure to get everything to look consistent.  So the next step is to get the List View showing what I want.  In this case, it is the Title column grouped by the Posting Date.  To do this I will:

1. Bring up the context menu and select the Fields option (Fig 1.1). 
2. Setup the columns to the Title field I would like (Fig 1.2).  
3. Bring up the context menu and select the Change Layout option (Fig 1.3). 
4. Setup the List View options I would like (Fig 1.4). 
5. Bring up the context menu and select the Sort and Group option (Fig 1.5). 
6. Setup the columns to the Sort order and Group by properties I would like (Fig 1.6). 
7. Right-click the List View and convert to a Data View (Fig 1.7).

That is as close as I am going to get with the List View. 

Figure 1.1	Figure 1.2

Figure 1.3	Figure 1.4

Section 2 - Modify The Data View Look And Feel

Now we have ourselves a Data View that is close, but still pretty far away from what we want.  We have our view set to group by posting date, but not by month and year yet.  So it is time to get our hands dirty with the Data View. 

1. The easiest way to work is through the design surface so we start by right clicking next to the Title  column header and selecting Delete -> Delete Rows (which is not needed since we are going to be doing a lot of grouping and things really should already be sorted by published date) (Fig 2.1)
2. We need to change the Group Heading for our published dates.  We can't have it saying Published: MM/DD/YYYY that just won't do.  Click on the first Published xsl:value-of element and just press delete 6 times (this is going to delete the Published column title text and the colon leaving us with just the date).
3. We are close to where we want to be now; all that we are missing is a count of the grouped items.  Luckily, this one is easy.  We will just click on the date in the design surface, which will highlight a portion of the Code View.  Then we'll paste in (<xsl:value-of select="count($nodeset/@Title)" />) which will give us a count of the number of items passed in to the template (Fig 2.2). 
4. The last change that is required will give us the setup for requirement #5.  We will need to setup a custom view for this, but knowing ahead of time what we need allows us to plan for it.  Once again, we are going to click on the first date to get our place in the Code View.  Now we will paste in <a href="{concat(substring-before(@FileRef, '/Posts/'), '/Posts/By%20Month.aspx?Month=', $fieldvalue)}"> which will be our link to the custom view we will need to make.  Essentially, it is a view that will be in the Posts list and it will have a query string with the value of our Group Heading.  Now we close off the <a> tag at the end of the Group Heading (Fig 2.3).

 That completes our Look and Feel changes.

Figure 2.1

Figure 2.2

Figure 2.3

Section 3 - Change The DataSet

So now we have updated how the XSL template for each group heading is handled.  Next we need to get the data to actually be grouped properly.  By default our list view has automatically grouped our data by posting date.  So we just need to modify what it has done, to group by posting month and year instead.  There are three main areas we need to change. 

The first is the NewGroup_0 variable which we will track down by doing a Find for NewGroup_0.  The Code View should show the xsl:variable tag, and inside there is a xsl:when that contains a xsl:value-of tag.  This is our first taget.  This will start our group creation so we will need to change the select statment.  By default you will see it checking if the Published date has changed.  We'll alter the XSL to this ddwrt:NameChanged(ddwrt:FormatDateTime(string(@PublishedDate), 1033, 'MMMM yyy'), 0) which checks to see if a formatted date string of the published date has changed (Fig 3.1). 

The next target is the groupheader0 xsl:variable which is located just a few lines below the NewGroup_0 variable.  This one has a xsl:otherwise with a xsl:value-of tag.  This will set our group header text so this select statement will be changes to ddwrt:FormatDateTime(string(@PublishedDate), 1033, 'MMMM yyy') which will set it to the formatted string we used when we changed the previous select statement (Fig 3.2). 

Our last target is in the xsl:call-template for dvt_1.groupheader0 which is just below the groupheader0 variable.  There is a xsl:with-param with a name of nodeset that we need to change the select statement for.  We will change it to msxsl:node-set($dvt_Rows)/root//Row[((ddwrt:FormatDateTime(string(@PublishedDate), 1033, 'MMMM yyyy'))=$groupheader0 or ((not(ddwrt:FormatDateTime(string(@PublishedDate), 1033, 'MMMM yyyy')) or ddwrt:FormatDateTime(string(@PublishedDate), 1033, 'MMMM yyyy')='') and $groupheader0=' '))] which will select the data based on the formatted date string of its published date matching our group header (which is in Month Year format) (Fig 3.3).

Figure 3.1

Figure 3.2

Figure 3.3

Section 4 - Putting It Into Play

Well we actually have our Data View all setup now.  We can save it and it will have everything we were hoping for except #3, but getting it in to the navigation is the easy part.  Right?  One would think so; however, the Blog template has some special characteristics around how its pages work.  There is a new web part zone added to a few pages called the BlogNavigator so you have to actually export the web part and add it to these pages in their BlogNavigator web part zone:

• default.aspx
• Lists/Posts/Post.aspx
• Lists/Categories/Category.aspx

After you have done this, you will need to open up the master page and add it there as well for all of the pages that are not listed above (assuming you want to).

Section 5 - Extra Credit

With any Data View web part there comes a problem: how can I make it reusable?  I am only aware of two ways.  Either make the Data View a part of an STP file, and it should automatically find its new list when the new site is provisioned, or make changes to bind to a list name instead of a GUID.  This will also find the new list in a provisioned site and has the benefit of being able to be exported and used on anyone's system without them having to edit it.  The instructions for how to make those changes are here.

Wrap Up

So while SharePoint might not have the capabilities of some Blog software out of the box, you can see that it is possible to use the raw materials to fashion what you need, and in a lot of cases I think you will find that you can do it without having to write and deploy code.  There are many ways to do things codelessly inside SharePoint.  We will take care of requirement #5 in What is Missing in the SharePoint Blog Template (pt. 2).