Web Part Follies

  • [アーティクル]

Every development effort of any complexity will pursue a folly or two at some point during the development cycle - by follies I mean those yellow brick roads down which the developers will toil without reservations or second thoughts, only to find that they’ve built themselves the wicked witch’s castle without a ruby slipper in sight.

In my efforts to provide technical guidance for SharePoint development teams I see a number of the same follies being pursued - sometimes by multiple teams simultaneously within the same organization – all soon finding themselves shoulder to shoulder peering up at those black walls with a troop of Winkies traipsing by singing "O-Ee-Yah! Eoh-Ah!".

So this is my personal list of web part follies that I wish to share in the hope of keeping at least a few present and future development teams firmly on the SharePoint pavement and off the yellow stuff.

And do note that I am only talking about SharePoint v2 here (the wizard is alive and well in SharePoint v3!).

  1. The Shared Workspace Task Pane (SWTP) Whammy

    1. This is a biggie and I’ve seen it way too many times. A development team builds a wonderful and complex solution that does some really cool things, and then at the very end they realize that the Shared Workspace Task Pane lets users bypass or even break their application.

    2. Such as? The SWTP gives the user full control of the documents in the library including delete, checkout, versioning, alerts, etc. And it gives the user control of the members of the library including add and delete if the user has the rights. The SWTP is very powerful and every SharePoint application architect needs to respect it -- because essentially the Shared Workspace Task Pane in Office 2003 is immutable. There is no supported way to modify it or change it’s functionality.

    3. Are there workarounds? Yes, and I could tell you about them but then I’d have to kill you.

    4. Have I ever skipped down this yellow brick road hand-in-hand with the rest of the team? Absolutely.

  1. The Event Handler Lock/Update Conundrum

    1. Now follow me close here, this is a little complicated.

    2. When opening a document from a Document Library for editing in Word, no document library event is fired.

    3. When closing a document in Word from editing mode, no document library event is fired.

    4. While a document is open for editing in Word, it places an “implicit lock” on the row in the SharePoint list so that it can’t be updated.

    5. If you click on Save in Word while you have the document open in editing mode, it does in fact fire the Update event handler.

    6. So typically the requirements will specify that the metadata for the document is to be updated when the document is saved. But you can’t in this case, because the row is locked. And added to that, since there isn’t any UnLock event, there isn’t any obvious way to update the data after the row is unlocked.

    7. Is there a work around? A couple and they’re not pretty. If anyone out there knows of a good one, please post it!

  1. The Upload New Version has no Metadata Blind Sider

    1. Ok, this one’s subtle.

    2. You think everything is working fantastically with your metadata being updated by your event handler assembly -- but at some point you notice that every once in a while a doc shows up in the library that doesn’t have any metadata.

    3. If you upload a document with the same name as an existing document (update by upload) then that new version will not have any metadata. The Insert event handler doesn’t fire because it’s an Update, and even if it did, you probably don’t want generic metadata at that point anyway. You want the metadata that has evolved along with the original document.

    4. Is there a work around? I know of one. Turn on versioning. Create a handler for the OnUpdate event. Check if the updated document has metadata. If not, then it was uploaded. Walk down the versioning list until you find the last set of metadata. Update the metadata of the new version. And finally, Delete all the old versions.

    5. Complicated? Yes. Does it work? Yes.

  1. The Site Definition One-Offs

    1. Have you ever noticed when you create a Shared Document Workspace in Word that it never asks you to select a template? That’s because Word already knows which template it is going to use, and the user and the developer do not have the power to change it’s mind.

    2. You can modify the site definition, like any other site definition, but there’s only one template for all of the sites created from within Word on a particular server. Not one per portal, one per server. So if you want to have one style site created from Word for one set of users on one particular Portal, and a different one for another set of users on a another Portal, you can’t. There’s only one.

    3. Likewise in SPS there is only one MySite definition and it is captured when you create the Portal. If you want a custom MySite, then you have to design it before the Portal is created. Afterwards it’s too late.

    4. Same thing with the SPS homepage. There’s only one, and it has to be designed before the Portal is created.

    5. Workarounds? You can modify the SPS MySite and Home Page after the Portal is created using Frontpage, but then it will be unghosted. And scaleability loves a ghost.

  1. The InfoPath Library Type Zinger

    1. When you create a custom form library, you’ll find that you are unable to use the Publish “to a SharePoint form library” functionality.

    2. And why is that? Somewhere in the innards of InfoPath it has been coded to Publish only to lists of Type="115". But the recommended practice, if you want to customize any list in SharePoint, is to always make a copy of the list definition, and give it a new Type ID. But unfortunately, if you give it a new Type ID, InfoPath will never ever ever consider publishing to it.

    3. Is there a workaround? If you’re all alone out there in big huge empty green field, then you can break the rules and customize the Type=”115” list definition. If the field isn’t so green, and there’s a big crowd around, then you’ll have to train your users to use the Publish “To a Web Server” option to publish to the customized form library. Just feed it the url to the forms folder in the library.

Ok, enough for now.

For those Developers out there who are right now today involved in SharePoint customization projects (and undoubtedly we already outnumber the entire Munchkin race by at least 10X) I will bet anything that there are a few, at this very moment, who are wandering down one or more of these very same yellow brick roads.

Wake up now! You are not Dorothy!

Michael

Comments

  • Anonymous
    May 31, 2006
    Great article.  I'm new to SharePoint development, and I'm feeling the pain.

    I've written an event handler to capture the update event and move the document to a document library based on a custom property.  When this happens, I want to add a few custom properties and send it on its way.

    The problem I'm having is the document are saved to the Word document, but not promoted up to SharePoint.  Is there  a way to programmtically promote the properties?

    Could you shed some light?

    Here's the code:

    oItem.Properties.Add("Accepted By", listEvent.UserLoginName)
    oItem.Properties.Add("Accepted Date", Now)
    oItem.MoveTo("Approved Documents/" & oItem.Name)