This is a little trick, but a useful one all the same. When you use the Publishing Site template for a site, you do not have the option in Site Settings to save the site as a template for reuse. There are probably good reasons for this due to the underlying structure of Publishing Sites, but no one has ever been able to explain it to me in any detail.
The trick is to append _layouts/savetmpl.aspx to the URL of your site. So, for example, if your site is at http://servername/site, you would use the URL http://servername/site/_layouts/savetmpl.aspx. On the Save as Template screen, you’ll probably want to check the ‘Include content’ box so that the .aspx pages in the Pages library are included.
Be careful with this, but as long as you haven’t done anything fancy in your site, it ought to work just fine. The template that you save will be available when you create a new site under the PublishingSiteTemplate tab.
A great way to manage the values for a Site Column in SharePoint is to put the values into a list and then use the Lookup column type to grab the values. When you allow multiple selections in the lookup column, what is stored looks something like this:
If you would like to then check in a DVWP to see if a value was selected, it’s not as simple as you’d like. If your values are truly unique and cannot be nested (e.g., School and Schoolhouse both contain the string School), then you can use contains. Otherwise, you’ll want to tighten things up a bit by doing some fancier matching.
The possible ways that we can have a match are:
- The multi-select string matches the value exactly. This is the case when there has been only one selection made, and it is the one that we want.
- The multi-select string begins with our value followed by a semicolon (value1;)
- The multi-select string has the target value in the middle, therefore surrounded by semicolons (;value2;)
- The multi-select column contains the value at the end, preceded by a semi-colon (;value4)
To test for each of these conditions, you just need a little logic in your XSL. Here’s an example that works when you want to see if MultiSelectColumn contains DesiredValue.
<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row[
@MultiSelectColumn= $DesiredValue or
starts-with(@MultiSelectColumn, concat($DesiredValue, ';')) or
contains(@MultiSelectColumn, concat(';', $DesiredValue, ';')) or
substring(@MultiSelectColumn, string-length(@MultiSelectColumn) -
string-length($DesiredValue), string-length($DesiredValue) + 1) =
Depending how you will need to do the test, consider creating a template that you can pass the multi-select string and the desired value, passing back the results of the test. You can store this template in a separate file and then use the template in many DVWPs by including it with xsl:import.
This one is a little embarrassing to report, because I’ve been frustrated with it and just living with it so long. However, maybe it will help a few of you out there.
For a very long time, I’ve been getting regular script errors in IE7 on Vista. I assumed that it was some artifact of the additional security that Vista provides and I just decided to ignore it. Finally I got frustrated enough to try to fix it, and boy is it easy. Just make sure that the setting ‘Disable script debugging (Internet Explorer)’ is checked in your Internet Options / Advanced tab, as below.
I love my iPhone. I mean I *really* love my iPhone. I’ve had it for about a month and a half now, and it is truly an amazing piece of technology and extremely well done. As most of us who are fundamentally Microsoft folks say, “Microsoft take note”!
However, here’s a little bugaboo with SharePoint that I can reliably reproduce. I’ve set myself an alert on a SharePoint Document Library on a WSS site. When I receive one of these alerts on my iPhone through my hosted Exchange account, it comes through fine. However, from that point forward, the pipe is clogged: no more email messages come through until I delete the alert from my iPhone. This makes little to no sense, as the contents of an email ought not to make a whit of difference, but I can reproduce it at will. I haven’t been able to figure out exactly where in the chain that the problem is, but I’m fairly certain that it is in the interaction between the iPhone and hosted Exchange.
Anyone else seen this?
UPDATE 2009-07-31: It occurred to me today that this hasn’t happened in a while. Maybe the 3.0 OS upgrade fixed it, but I can’t say for sure.
I’ve always been a lazy programmer and if you can believe it, I see this as a good thing. I never want to write anything more than once. (I’ve written an assembler-based keyboard handler for DOS. Do I need to do it again? As much fun as it was: no.) I also believe that the simplest way to solve a problem can often be the most elegant one.
With SharePoint, there are basically three “tiers” where you can do development: in the UI, in SharePoint Designer, and in Visual Studio. To me, you should think of the tiers in that order of preference, which goes from simplest to more complex. I ran across several posts today that I think back me up.
Thanks to David Whittle in Japan for the pointer to the Path to SharePoint blog. In it, Christophe shows us how to do some pretty amazing things by generating HTML in calculated columns, among other things. I might turn to SharePoint Designer for some of the things that he pulls off, but his approaches work just fine, depending on your environment. For instance, your governance rules may preclude you from using some of his techniques (You do have a well-documented governance model, right?), but that doesn’t make them bad approaches, just not the right approaches for you.
Christophe had a pointer to Joel Oleson’s blog where Joel talks about Webpart and Widget No Assembly Required Simplicity. Joel’s premise is that you can do a heck of a lot by using script-based widgets in SharePoint without actually writing *any* code. (Sure, you may need to configure a widget’s script through someone’s Web page UI and drop it into a CEWP, but that doesn’t count as writing code in my book.)
All in all some more strong arguments against needing a top notch .NET programmer to do very cool and useful things on top of the SharePoint platform. In these days of mashups and instant apps, don’t rule out these same approaches from being highly useful in a serious business application, either.