When saving data into Web Part Properties, remember [Serializable]

So, previously I’d described using a Web Part Property of an ArrayList to store a list of things. In that demo, I’d been just storing strings.

Well, my requirements got a little more complex, so I started trying to store my own objects in there – really, just objects storing data, no logic. However, when I added things to the property and ran .SetPersonalizationDirty() my data wasn’t saved. Worse, the values of other (unchanged) web part properties were lost! They kept coming through as null, rather than the values I’d set previously. There was no indication of error.

Well, here is Andy’s tip for folks who manage to forget the basics of C# development – don’t forget the [Serializable] attribute.

Without it, my data objects can’t, well, be serialized – that is, saved. So it’s unsurprising that my data wasn’t saved! What was unfortunate and threw me off the sent was that there were no errors shown, and that wiping out the values of the other web part properties did rather thrown me off the scent! I guess I was really having an off day when I wrote that…

When saving data into Web Part Properties, remember [Serializable]

Style individual web parts

Like Heather Solomon, I’m sometimes asked about styling individual web parts differently to the rest. I didn’t know of any way of doing this; instead, we’d typically style particular web part zones differently, but this meant that all web parts in that area looked differently.

Well, Heather has now posted ‘Controling single web parts with CSS‘. Neat. I didn’t know you could do that attribute selection.

The downer about this technique is that you have to set a DOCTYPE – and I can see that causing all sorts of grief as stuff breaks… …so it’s probably not something you’d do unless you’re building reasonably custom master page.

Style individual web parts

Notes on the Microsoft.SharePoint.WebControls.DateTimeControl

It’s quite nice that this control is available to use in my own pages/web parts, but there are issues:

Here we have in microcosm my problems with Microsoft and date/times – an assumption of the local region, and date time controls that would never be empty, right? I had exactly these same problems when writing an Outlook 2003 to SharePoint 2007 integration too. Makes me a bit annoyed! Especially as we have nullable types! Quit screwing around with DateTimes being structs, make them objects and just return me a bloody null if nothing has been selected!

Notes on the Microsoft.SharePoint.WebControls.DateTimeControl

Search a single Site

Previously, I’d posted about a customer who wanted to search a single list from a Search Box web part, but have their results shown in a Search Center results page. We ended up using a custom scope to do that.

This time, I’d a slightly different requirement. Another customer had a number of links, and these links would include search terms. They wanted to be able to restrict those searches to particular sites – and not just one particular site or set of sites, but to lots of different sites.

This made adding a scope an unappealing prospect. You’d have to add lots of scopes, and it’s not very dynamic.

One thing you can do in SharePoint search is search on the value of a particular managed property. A normal search would have query parameters like:

?k=King%20Lear

That would search all of SharePoint for ‘King Lear’. Well, we could also filter by properties – so we could do a search for:

King Lear site:http://intranet/somesite

This would encode to:

?k= King%20Lear%20site%3Ahttp%3A%2F%2Fintranet%2Fsomesite

and would restrict our search to a particular site (and subsites, actually – but close enough!)

This set me wondering, though – there is a URL managed property. Could I use this to restrict my search, rather than having an additional scope? Trying to restrict the search based on this didn’t seem to work very well. My results were… strange. I can’t figure out a logic, other than I was missing a lot of results. If anyone figures out what was going on, let me know.

So, the short is, I believe the above is a good way to restrict your results to a site. However, I can’t find an easy way of restricting results to a single list via a URL. I might have, if I’d spent longer looking!

Search a single Site

Storing Data within Web Parts

We have a customer who wants a custom web part similar to the Summary Links web part – that is, editors can add links in this web part (along with some other metadata). For various reasons, a ListView web part and a Links library weren’t what they were after.

Now, the Summary Links web part seems to me to be a bit unusual. Most web parts access and use data stored elsewhere – lists, web services, databases, etc.. However, the Summary Links web part stores it’s data internally. How does it do that, and can I do the same? Continue reading “Storing Data within Web Parts”

Storing Data within Web Parts

Search a single list, and don't use the OSSSearchResults.aspx page…

So, we’ve got a customer who’d hit the problem of the OSSSearchResults page that I’d mentioned before. To recap:

  • Global Searches in MOSS use a Search Center page for showing the results. These are nice, configurable, and can be made do quite a lot.
  • Contextual Searches (such as a particular list or site) use the standard WSS OSSSearchResults.aspx page. This isn’t nice and configurable, and changes will affect many sites.

Now, what would be great would be if we could have the contextual scope, but the global results page. Well, we can. Continue reading “Search a single list, and don't use the OSSSearchResults.aspx page…”

Search a single list, and don't use the OSSSearchResults.aspx page…

"How to Optimize SharePoint WCM for Performance"

Really, this is just a link to the MSDN article “How to Optimize a SharePoint 2007 Web Content Management Site for Performance“. Nice easy title.

It does mention a particular irritation of mine – that many (most?) systems don’t use any kind of compression on static content. I remember seeing Apache admins complaining about people not using compression, oh, 10 years ago. In SharePoint, this is such a waste! JavaScript and CSS files are lovely and compressible – and core.js is big. So is Core.css. Doesn’t seem much reason not to enable it!

To do so, open IIS Manager, and right click on the ‘Web Sites’ folder. Select the service tab, and check the check box. Don’t go for dynamic compression; this would be a bad idea.

iis-compression

You’ll also want to check/edit the file types compressed. See Using HTTP Compression for details, and you’ll probably need to add the .JS and .CSS extensions.

I must sit down and give this a proper test some time. Certainly I don’t see the same sizes in the article, but then I’m looking at the file sizes on disc; in 12 Hive, and in the temporary compression cache (typically %WinDir%/IIS Temprorary Compressed Files). My numbers show Core.js to be 575Kb uncompressed, 91Kb after compression. Nice!

"How to Optimize SharePoint WCM for Performance"

Page hit counter in MOSS

So, a customer of ours is upgrading to SharePoint 2007. One of the things they were looking for is a hit counter, so they can see the number of times a page was requested. This was easy for them to do in SharePoint 2003 – they’d just use FrontPage, and insert a Hit Counter web component. I’d never heard of such a thing build into 2007, but over morning coffee, I decided to give it a try. Much to my surprise, it works… …sort of.

There is a hit counter (albeit with an awful set of styles). It does work too:

Hit counter in SharePoint

That’s one of the better styles, believe it or not. So, what’s the problem with this?

Well, in normal pages, nothing. It counts; ’nuff said. However, publishing pages are a bit different. They store metadata in a ‘Page Content Type‘ and then use Page Layouts to render that data. What this means is that many things that appear to the user as separate pages actually use just one ASPX file for rendering their content – and this is where the hit counter doesn’t work. It counts the number of hits on the ASPX page – so instead of getting a number of hits on that page of content, you get the number of hits on content using that page layout. Which sucks a bit.

I’ll look into this a bit more soon, and see what I find. It can’t be that hard – apart from the whole ‘Page Layout’ thing, it’s not exactly rocket science.

Page hit counter in MOSS

Feature Stapling for Branding

As I’ve mentioned before, I reckon that from now on I’ll do all SharePoint branding through features alone – not using themes or the ‘choose master page’ page. Which is fine, and useful too – one of the questions that has been raised recently is how to automatically apply the branding when a new site is provided. Well, feature stapling is the way to do that.

For those who don’t know, feature stapling is creating a feature which associates another feature with a Site Definition. When a site is provided by that site template the associated feature is activated. So, for example, we might have a BrandingFeature feature, which does all of our setting alternate CSS, setting master pages, etc., and then use a BrandingStapler feature to associate that with some (or all) of our site definitions.

I won’t bother repeating the ‘how to’ of it, as there are plenty of good posts about it.

Feature Stapling for Branding

WSS Practice: Create a list, columns and view programmatically

Next task on my prep – create a list programmatically. Then I want to add some columns to it, and show these on the default view. Actually, it’s mostly pretty easy (apart from that last part). Continue reading “WSS Practice: Create a list, columns and view programmatically”

WSS Practice: Create a list, columns and view programmatically