I was reading Andrew Connell’s book ‘SharePoint 2007 Web Content Management‘ and it made something crystallize for me. I’ve been pondering this for about 8 months or so, but I believe that several of our customers are using the Publishing features of MOSS incorrectly, and that simply basing sites on out-of-box Collaboration and Publishing site templates is a mistake.
(Well, at least without additional planning) Continue reading “Plan Your Publishing Pages”
I read a post by Alexander Brütt about programmatically creating a Lookup column, and I thought I’d post my code from a slightly longer article a while back. It’s quite an interesting thing to do!
SPList targetList = site.Lists["My Lookup Target"];
SPField targetField = targetList.Fields["My Target Lookup Column"];
newList.Fields.AddLookup("NewLookup", targetList.ID, false);
SPFieldLookup lkp = (SPFieldLookup)newList.Fields["NewLookup"];
lkp.LookupField = targetField.InternalName;
lkp.Update();
I keep forgetting how I did this and having to dig into old demo VMs – you can display hyperlinks via calculated columns:
Yup, the AnimalName column is calculated, and consists of a URL and a search term which is the item’s title:
Although it doesn’t show it, [ID] is also a valid column to insert.
Sadly, I’ve not figured out how to display a ‘pretty’ calculated column yet – for example one that just showed ‘Click me‘ rather than the full URL. Still, I thought that having a link to search was interesting. And naturally, if you use the DataView web part then setting up the link with a ‘pretty’ link is trivial.
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…
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.
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!
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!
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”
So, we’ve got a customer who’d hit the problem of the OSSSearchResults page that I’d mentioned before. To recap:
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…”
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.
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!
Andy Burns' Blog 