Code

A great post on how to use Subversion properly

Bil Simser over at the Fear and Loathing blog has put together a very good tutorial on how to use Subversion properly, including branching and revisions.

He has pictures, and goes very very slowly which is helpful for “one repository, one code base” people like myself.

It’s crystal clear, and if you use Subversion, will actually make it easier for you to use.

Ta Bil

By admin on May 30, 2008 | Code, Development | A comment?

Dataview web parts in your master page cause errors on subsites

If you’ve had this problem, then two things to make you feel better:

  1. The solution is very easy
  2. The cause of the problem is stupid stupid stupid. You can bang your head against the keyboard, there’s no way you could have known.

This post, meanders a bit, so if you want the solution, jump to the bottom.

Still here? Sucker.

So, what are the prerequisites to causing this problem:

  • you have a dataview web part inserted into a master page;
  • the dataview refers to data in a list; and
  • the list is scoped at the root web of the site collection.

I think that’s it.

Symptoms

The web part will display correctly anywhere in your root web, but nowhere else. I’m calling it a “web” here because it maps to how Sharepoint’s API. If it helps for you to think about it as a single “Site” in WSS2.0 fashion, go nuts. When you visit subsites, you see the following error:

“Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.”

How helpful, especially if you’re an administrator or developer. As if they’d have a magic wand to fix the problem. The error might as well say:

“You’re screwed. Unless you’re a clever developer, give up, swear at Sharepoint and call tech support. Not many people at your company are going to be able to help you.”

Which is silly, because once we come to the cause, the error is completely within the realms of detection. To the developer who wrote that line of code… 10 minutes on the naughty step.

The problem is seemingly unresolveable. If you try to add the dataview directly to a page in a subsite, it works fine, but master page? Sharepoint tells you to go whistle.

Cause

The cause? Sharepoint doesn’t know which “web” the list comes from.

The Dataview web part can take parameters, including, parameters which tell pages where to find a list. In Sharepoint Designer, when you edit a master page, it fails to insert a parameter telling pages the list lives in the root.

Bad Sharepoint Designer! Bad!

The problem compounded because taking a dataview created on a subsite and dumping the code into the masterpage doesn’t work either (which makes it very tricky to solve).

To figure this out, I took the following steps in Sharepoint Designer:

  • Created a dataview in the master page (worked at top level and nowhere else)
  • Created the dataview with the exact same settings on a page in a subsite
  • Copied the code snippets into a text-editor and compared them side-by-side

A side-by-side comparison revealed several things…

Web part parameters in the master

Web part parameters in a page

First, the datasource control (a child of the dataview web part) is referred to with a different namespace in the master page than in the page itself. This is why you can’t copy dataview code from a regular page into a master page. Maybe there’s a good reason for having done this, but I think the masterpage programmer forgot to speak to the regular page programmer. However, that isn’t the root cause, but something to be aware of.

Second, THERE’S ANOTHER PARAMETER. OMG!!! Froth, swear, stomp, swear, slam your keyboard. Feel better?

Knowing a parameter exists and knowing the syntax are two different things. Before finding the actual code, I was pretty confident the problem was down to subsites not knowing where the list was.

The worst thing is that the url of the web is actually part of the dataview web part, down at the very bottom of the code. Why doesn’t this flow through to the datasource? Naughty step!

Web part parameters

Solution

It’s simple enough to copy the parameter from the subsite dataview into the masterpage dataview.

<WebPartPages:DataFormParameter Name=”WebURL” ParameterKey=”WebURL” PropertyName=”ParameterValues” DefaultValue=”/”/>

I don’t believe the approach is necessary if you’re referring to a list in a subsite (the parameter should be inserted automatically).

Hope that helps!

Relative URLs in Sharepoint Web Parts

If you’re using STSDev for web part development, it becomes very simple to deploy files into the 12Hive (which in some circumstances is preferable to using embedded resources). As a consequence, it becomes tricky to create hyperlinks to resource files because:

  • you can’t guarantee the web part is sitting in root of the site collection (which would make for simple hyperlinks ala “_layouts/styles/myPart/myCSS.css”)
  • you can’t know that your site collection is located at the root of the web server (which would make for simply hyperlinks ala “_layouts/styles/myPart/myCSS.css”

So, to create simple relative urls from code (as opposed to using the <% $SPURL:~sitecollection/_layouts/styles/myPart/myCss.css %> approach) I used something I found on Ari Bakker’s website.

Deep underneath the SPContext object is a property called ServerRelativeUrl which is attached to the Site(SPWeb) and Site collection(SPSite) objects.

These can be used by the web part to refer to resource files deployed along with it. So, something like the following should work anywhere inside a site collection:

string cssLocation = SPContext.Current.Site.ServerRelativeUrl + “_layouts/styles/myPart/myCSS.css”;

By admin on April 21, 2008 | ASP.NET, c#, Code, Development, Sharepoint | A comment?

Five star service is…

…when you show up at the coffee shop in the morning and your regular joe is ready before you get to the front of the line.

Thanks coffee lady! (I go to Nero)

By admin on March 17, 2008 | Code, Design, Service, Strategy | A comment?

I don’t want to download Silverlight!

The various Microsoft websites are becoming increasingly frustrating to use.  Why? 

They all try to force me to download Silverlight, their answer to Adobe’s Flash.  Popups and banners everywhere.

 

Why use Silverlight?  Microsoft’s answer >>

Zzzzzzzzzzzzzzzz.  Until sites other than Microsoft.com don’t work without Silverlight, I think I’ll stick with Flash. 
By admin on January 2, 2008 | Code, Design | A comment?

Skinning

It is quite hard to create a skin for Mediawiki and WordPress. I have spent the past few days finishing my mediawiki one. Now I am building an identical skin for WordPress.

Most of the cross-browser compatibility issues for both apps have been resolved. My current challenge is to create a generic approach for wordpress sidebar widgets.

By admin on September 3, 2007 | Code | A comment?

Mediawiki skin close to first release

My new Mediawiki skin is almost ready to be used in anger. The most difficult part has been building in Internet Explorer compatibility. The latest version is visible on my wiki.

I spent several hours last night tweaking my skin to make it work with Firefox (yay), Safari (yay), and IE (boo). IE was by far the most difficult, with many little tweaks required to get it just right.

I want to spend some time using the skin myself before packaging it for download. I also want to port it to WordPress (and possibly Gallery) so my entire site can have a consistent look.

By admin on September 2, 2007 | Code | A comment?