Centrally-managed InfoPath data connection libraries

Call it laziness if you will. I never got around to testing the use of InfoPath data connections in a centrally-managed library. I hadn't given much consideration to the benefits of placing UDCs there instead of a Data Connection library.

Well, I tried it for the first time yesterday, and wow, there's one really really large benefit - it's MUCH faster than placing them in document libraries. I assume there's some overhead having to do with checking permissions, plus there's likely a dedicated service path to get centrally-managed UDCs whereas I expect InfoPath uses the List service to fetch them in IPFS forms. In my old environment, when opening new forms that had list data connections that load on initialization, form launch would often take 5-10 seconds, whereas now it's a tenth of that.

I hope this performance holds out in 2010! Now, if only the administration/management of those UDCs was more refined...

Webparts and STSDEV

I'm pretty used to doing 2007 development with STSDev and I've gotten really comfortable with it. However, one of the things I haven't built yet, amazingly enough, is a webpart.

So, last week, I was trying to find a world clock webpart that would properly observe DST where applicable. Amazingly, only one I was able to find does, but it sources external Flash content as part of its rendering. Instead, I decided to get the CKS release of the Bamboo World Clock and Weather webpart and put proper DST support within.

The code itself is...amusing to say the least. If I didn't know better, I'd say it was intentional to have the main namespace "CKS.Bamboo.WorldCockAndWeather".

At any rate, the CKS project makes a solution, but it's not feature-activated. STSDev has support for webpart-based projects, but crashes when parsing ClassResources. So, in my infinite wisdom OCD, I'm moving the Bamboo code into a STSDev project, and now I find myself modifying the source of STSDev to incorporate support for copying ClassResources into the Manifest, and proper storage of the data within the DDF.

2010 can't come soon enough.

Working with Acrobat Shared Review and SharePoint

I guess you could say I'm something of a stick in the mud. Acrobat peaked for me around version 5. Years ago, probably around the time that Adobe began insisting on using a download manager to download a copy of Reader, I threw my hands up and started using GhostScript/GSView, and PDFCreator when needed. If I really needed to use Acrobat Reader for something, like to fill out a PDF Form, then I have a sandbox VM with Reader installed for that very purpose.

Flash forward to today. My new workstation has Acrobat X installed, and several people in my company use a specific feature offered since Acrobat 8 called Shared Review. Pretty simple, you can annotate PDFs and those annotations are shared so that other users can view them. The annotations can be recorded on a driveshare, or naturally on Acrobat.com if you feel like engaging in that sort of thing. You can also store them on SharePoint as it turns out, and this is how things are done within this particular department.

When the comments are refreshed, the local copy of the PDF is rewritten with the comments cached within, so the "offline" copy travels with the most recent available annotations. Because each of the PDFs with Shared Review configured also points to a saved location for comments and updates on launch (as well as at will with a button inside Acrobat), you can have 30 copies of a PDF distributed about, and given a network connection, everyone's comments should be visible.

We're in the process of rebranding our primary SharePoint instance and restructuring it to adhere to a new "Information Taxonomy" as my boss calls it. New URLs, content relocation, the whole nine yards. We were all set at the 11th hour to pull the trigger and deploy our updated site when we discovered that we hadn't accounted for how the Shared Review PDFs would work. When a PDF is set up for Shared Review, a new copy of the file is saved that contains connection information to the location where the comments data is stored.  It turns out that when this environment was set up, the location for those comments was buried two subsites deep, since the staff members originally working with this product worked in that location in SharePoint.

So now, we have several hundred PDFs that have connection information embedded within them (encoded, naturally) which points to http://server/department/section/Comments, and tomorrow, this site will instead be stood up at http://newserver/division/office/department/section/ , and Acrobat appears to offer no way to change where that connection is pointed. We had a number of ideas about how to tackle this issue, but other questions started to come up. These files are being used around the world, with some offices that don't have reliable bandwidth. Are they using the "master" copy being maintained within the project site? Are they using a local copy? Are they using something else?

It turns out that when you set up Shared Review, you have three options on distributing the updated PDF (which contains the location of where the comments go):

1. Send an e-mail with the new PDF as an attachment
2. Send an e-mail with the PDF hyperlinked
3. Don't e-mail it at all

In all three cases, Acrobat creates a local copy of the PDF. In the second case, it also uploads a copy of that PDF to the same document library where you requested it to save comments. In our case, the users were putting the review-enabled PDF up on SharePoint in a different location anyway, so now we have a few hundred PDFs that are effectively orphaned clones.

Anyway, since Acrobat does not appear to offer an easy way to manage this data connection for Shared Review, we now have to go back and touch all of these documents to point them to a new location where comments will be stored. In order to insulate them from any further path changes, we're going to create a new web application/site collection solely for Acrobat documents, and host the documents there, outside our current setup.

So, the moral of the story is - it's a nice feature, but use some caution when planning if you intend to stick with it in the long haul.

Minor gotcha with owssvr URL queries

Sorry for the lack of posting recently, I had to gear up quickly for a relocation, and now that I'm mostly settled in my new house, it's time to get back on track!

I encountered an issue today in some forms I've been working on. I was using a URL query into SharePoint to get an XML-formatted subset of list items from a SharePoint list. If you're unfamiliar with this, you can essentially use a URL in the following format to get an XML-formatted chunk of data from SharePoint and process it however you like:

http://webroot/sites/sitecollection/_vti_bin/owssvr.dll?Cmd=Display&List=GUIDofSharePointList&XMLDATA=TRUE&FilterField1=ColumnTitle&FilterValue1=Whatever&FilterField2=AnotherColumnTitle&FilterValue2=Stuff

I have an InfoPath form that's using this to populate a drop-down list. We'd never expected this list to get long, but the business unit involved grew this list from 15 entries to more than 120 in between versions, and I suddenly found that the list was not returning all the items.

It turns out that the data returned using this method is partially affected by the settings for the Default View for that list. The default setting for SharePoint views usually limits list output to batches of 100. I upped this to 1000, and now I get all my list items. Fantastic!

Certified! (or certifiable!)

I took MS 70-542 yesterday and passed it, so now I've passed both the WSS and MOSS development exams. I've not really found either of them to be tremendously relevant to what I already do in SharePoint, but that can be just misapplication of the tech. A lot of what is covered on 70-542 I would normally do in Central Admin. Yes, it is a *development* exam, but still - the "every problem is a nail when you only have a hammer" truism applies here.

Formula lists for Calculated Columns

It seems like SP builders always find themselves having trouble finding a resource like this when they need it. It used to be that the Office online documentation was scant and threadbare, but apparently Microsoft has fixed that, and this document is very thorough and detailed. I was looking for a "contains text" function, and they have an expression chain that does it pretty much just like how I'd set it up in Excel.

http://msdn.microsoft.com/en-us/library/bb862071%28v=office.12%29.aspx

Grand opening

In general, I've always had good opinions about tech blogs. Especially in my dealings with SharePoint. The documentation behind MOSS 2007 is almost non-existent, to the point where developing without Internet access is an exercise in futility.

I've just never really felt like I had anything of substance to say on the matter, and then finally I had a task recently which I felt merited writing about, and so it has pushed me to going through the trouble of creating a site to chronicle all the misanthropic adventures I have while working with the development hydra known as SharePoint.

I haven't had the opportunity to work with SP2010 yet, so I'll make no guarantee that any of this content will be timely or relevant, but hey, you never know.