Archives

Archives / 2005 / January

  • Zero touch RSS Web Part

    No Comments

    George Tsiokos wrote me about a service he put together and is offering for free (under the MIT Licence). You enter an RSS feed URL on his page and he'll generate a DWP file you can upload directly as a Web Part onto your SharePoint Web Part Page. It uses the DataView Web Part and XSL to perform the translation so requires no server software installation (except the upload which anyone with the add web part right can do). It produces a nice, clean, RSS feed from news items with a link to each entry. The title of the Web Part links to the parent site where the feed came from. His DWP file supports RSS 0.90, 0.91, 0.92, 1.0, and 2.0 versions as well as Atom and Microsoft's Channel Definition Format. You can check it out here on his site.

  • YASPQ

    No Comments

    I live and breath computers. Each and every day, for 12-16 hours a day, I sit in front of a computer spitting out various artifacts (mostly Internet Explorer/Firefox history links, but the occasional piece of code, application, document, or architecture that makes some kind of sense). Here's Yet Another SharePoint Quirk (YASPQ) that make me loathe that collaboration environment we all know and love.

    Security. Love it or hate it, it's all around us. After all, without it everthing would be well, unsecure. SharePoint and Web Parts (and the .NET Framework to a lesser extent) has a big tie-in with security. Writing Web Parts is pretty straight forward however you'll run into a few security hurdles if:

    • You want to reference other assemblies in your solution (things like domain objects or data access layers or the recently released Enterprise Library of application blocks, *very cool* and probably deserves a blog entry of it's own on incorporating them into SharePoint Web Parts so stay tuned)
    • You want to reference the SharePoint object model (what else would a SharePoint Web Part do?)
    • You want to make external calls to services like external Web Services or access sites using something like the WebClient or WebRequest classes.

    Just spitting out HTML in your Web Part is easy. Talking to the SharePoint Object Model (which you'll want to do if you want to display SharePoint information like lists of sites, document library info, etc.) is a little more tricky but can be easily fixed by changing the trust level to WSS_Medium. Talking to other assemblies can easily be accomplished by adding the [assembly: AllowPartiallyTrustedCallers()] which shouldn't be a concern (although it *could* open your assembly up to attacks from that yet to be created .NET managed virus).

    The three options you get with developing SharePoint Web Parts are evil, but balanced in a kind of masochistic way (much like writing Web Parts from scratch which I can now say I can do in my sleep and usually do).

    1. Increase the trust level of the entire virtual server. Best option to keep your development cycle happy (compile directly to the BIN directory or have a NAnt script drop it there for you) and no IISRESET required. Least secure though and affects all assemblies on the virtual server.
    2. Toss your Web Parts into the GAC. Less secure but easy to implement. Not a great development option though as you have to do an IISRESET each time you update the Web Part.
    3. Create a custom policy file. Talk about complicated (no less than 5 steps to implement this and a bugger to get it right if you don't know where all the files are located on the server). The most secure and basically the most flexible as you can tune the security to the Web Part itself. However I've never seen any commercial, freeware, or otherwise Web Parts ship with a policy file or install one.

    Anyways, a few options and definately something you should be aware of. Developing can be easy (and unsecure) and you can leave the heavy lifting up to consumers if you're creating Web Parts for others. In-house Web Parts *should* go through the motions and create and implement custom policy files so you can co-exist nicely with a locked down portal. You just need to do a little more legwork on these. Here are a few resources to get you more info:

    Microsoft Windows SharePoint Services and Code Access Security
    Creating Web Parts that Call Services
    SharePoint, Code Access Security and SmartPart

    PS I notice while I'm blogging on the .Text website my cursor is updating with each character I type and pausing from time to time. Must be something in the control doing an autosave of the blog, but it's damn annoying!

  • Leveraging SharePoint Web Part capabilities

    1 Comment

    I'm stuck. I think I'm caught between a rock and a hard place.

    Currently with SharePoint you have 3 ways to create web parts.

    1. Define the views and all that stuff and drop it on a page.
    2. Create a DataView Web Part (with FP2003) and drop it on the page.
    3. Create everything from scratch.

    With the first two options, you can get all kinds of nice features like column sorting, filtering, etc. Free. No coding required. With the second option, you can have all kinds of great business logic happening to render your information. Run off and talk to SAP, suck some data out of your corporate Oracle system, do some financial calculations, whatever. Then fire it off the web page all nice and neat for the user. Problem is that I can't find any !%@#$%$# way to find a happy balance between the two.

    What if you want to aggregate across multiple types of items or items that don't exist in a single library or list (like a domain collection)? Let's say I have 500 sites under a portal and each one has a Task list on it (we'll assume they're all from the same site definition). I write a web part to recurse through all the sites, grabbing the task list and finding all tasks assigned to Me and want to display them in my custom web part, with filtering, paging, sorting, etc. that the ListViewWebPart provides (assuming I have a list to point it at). I can't because I have nothing to point the listview at. Unless I create a new list on the fly (ugh) and populate it, but that's just plain ugly.

    ListViewWebPart would be nice to inherit from then specify your own data source (overriding the GetData method). However pretty much all of the classes in Microsoft.SharePoint.* are sealed (except for WebPart) so that's the only thing you can inherit from. For example, when you drag a web part onto a page, SharePoint will use the ListViewWebPart from it's arsenal to give you all those features people want (sorting, filtering, etc.). However you can't inherit from ListViewWebPart, only WebPart. The DataView Web Part is the same. I have to point it at a data source. Grant you it's a little easier because you could point it at a web service and have your web service do the heavy lifting, but still it's not very elegant or easy for that matter and I've never seen anyone do it.

    Anyone have any insight into how to bridge what I think is a gap here? While you can't inherit from a ListViewWebPart or a DataViewWebPart, you can construct them in your custom web part. Problem is you're still stuck having to point them at a physical source of information rather than a collection of domain objects.

  • .NET eBay consultants auction and the Tsunami Victims

    1 Comment

    Thought this was a great thing for people looking to get some expert .NET help and help out the Tsunami relief (why is Tsunami always spelt with a capital 'T'?).

    Julia Lerman and Stephen Forte have put together a unique .NET charity auction to help out. Thirty of the top consultants and trainers in the worldwide .NET community have come together to help raise money for an organization that is doing amazing and heroic disaster relief in Aceh Province, Sumatra, the hardest hit area of the Dec 26th Tsunamis.

    Bid for an hour of a .NET Celebrity Consultant’s time. Winners can pick the brain of a .NET Expert for an hour (highest bidders will be first in the “draft” for the consultant assigned to them). Winners can call, email or IM the consultant and use the hour to answer that nagging question, do a code review, or just get some general .NET advice.

    The participants are RDs, MVPs, and INETA speakers from all 6 continents and 12 countries and include:

    Michele Leroux Bustamante, Kimberly L. Tripp, Jonathan Goodyear, Andrew Brust, Richard Campbell, Adam Cogan, Malek Kemmou, Jackie Goldstein, Ted Neward, Kathleen Dollard, Hector M Obregon, Patrick Hynds, Fernando Guerrero, Kate Gregory, Joel Semeniuk, Scott Hanselman, Barry Gervin, Clemens Vasters, Jorge Oblitas, Stephen Forte, Jeffrey Richter, John Robbins, Jeff Prosise, Deborah Kurata, Goksin Bakir, Edgar Sánchez, Thomas Lee, J. Michael Palermo IV, Vishwas Lele, and John Lam.

    So how would you like one of these guys (or girls) come to your office, hang out, bring donuts, tell you everything about Visual Studio 2005 (breaking all kinds of NDAs in the process), try to convince you to use DataSets everywhere and that XML is the only language there is, do code reviews, help debug something nasty, convert your Java finance system to .NET, defrag your hard drive, organize your MP3s, or whatever. Check out the eBay auction site here.

    Sounds like fun to me, but then I was always kinda odd.

  • Text Files, Associations, and SharePoint

    1 Comment

    There was a really interesting thread (that I'm sure isn't finished) in the newsgroups around .txt files and their somewhat odd behaviour opening in IE and not the associated program (Notepad for most of us peons). Here's the original message that sparked this thread:

    What is the story behind the .txt files being overlooked when it comes to document libraries?  Should all .txt files be converted to .doc files?  It's a pain having to open them into IE, then 'Save as' to the desktop, open them with notepad, edit them, save them back to the desktop, then re-upload them to the document library.  There is no version history with that method either. Why can't we open .txt files to an editor from within the document library?  Is there some way in SharePoint to change the association for .txt files from IE to some editor?

    I didn't think it had anything to do with SharePoint or document libraries at all. File associations are an Internet Explorer/Windows Explorer thing, not SharePoint. True, SharePoint does do a little extra (through some cleverly embedded Javascript and some obscure onclick tags) but for the most part, it just does whatever any other .txt file does when launched from IE. It opens it in IE.

    I did some digging and found a few things that may help:

    Microsoft KB Article:
    http://support.microsoft.com/kb/q185373/

    Lengthy Article on File Associations (and mentiones IE and Text Files):
    http://antivirus.about.com/od/windowsbasics/l/blfileassoc.htm

    Contains "fixes" for file associations and includes one for text files:
    http://www.dougknox.com/xp/file_assoc.htm

    The last link *might* fix the opening of .txt files (I tried it but just seems to repair any .txt file association problem) but the other problem is that you can't get the Office like integration with Notepad for example. It just isn't there so you're never going to see Notepad have a task pane and Check in options like Word does. Nor are you going to see too many non-MSOffice products have this feature either. The entire Microsoft suite of products is something that continues to alter each other in behaviour and how say a Word document has new "features" when you open it from a SharePoint site rather than a hard drive.

    Some interesting stuff indeed. I did some digging and found a few more things.

    Okay, the Javascript I mentioned is the DispDocItemEx Javascript function (found in OWS.JS). If you look at how a SharePoint doclib displays it's files, it wraps a "<a href>" tag and assigns an onclick event with this for a Word document:

    <a href="document.doc" onclick="DispDocItemEx(this,'FALSE','FALSE','TRUE','SharePoint.OpenDocuments.2')">Word Document</a>

    Okay, fair enough. How about a text file?

    <a href="document.txt" onclick="DispDocItemEx(this,'FALSE','FALSE','FALSE','')">Text File</a>

    Hmmm. Different parameters and there's no last parameter. Looking at OWS.JS we find this:

    function DispDocItemEx(ele, fTransformServiceOn, fShouldTransformExtension, fTransformHandleUrl, strProgId)

    So the ProgId (the program to launch the file?) is something called SharePoint.OpenDocuments.2. Smells like COM or something but looking at the DispDocItemEx Javascript we find a call to a function StsOpenEnsureEx. Looking at this we find a LOT of code commented out! The commented out code contains this:

    //@cc_on
    //@if (@_jscript_version >= 5)
    //@            try
    //@            {
    //@                v_stsOpenDoc = new ActiveXObject(szProgId);
    //@                v_strStsOpenDoc = szProgId;
    //@            } catch(e)
    //@            {
    //@                v_stsOpenDoc = null;
    //@                v_strStsOpenDoc = null;
    //@            };
    //@else
    //@end

    Now my javascript is pretty rusty and this looks like a mish-mash of C# and various scripting languages but "new ActiveXObject(szProgId)" I recognize. Then I thought "okay, there's that KB article mentioned which is about downloading text files through an ActiveX object". Any connection?

    So, walk with me on this one, suppose the commented out code invokes ActiveX on the client (IE) and launches the appropriate client side program? Is this the missing link to get .txt files to launch with the association they have on the desktop?

    Also another thought is the order that .txt files are listed with their desktop associations. I looked at a few setups and default is that IE is first in the list, followed by others with Notepad mixed in there. Perhaps you can a) move Notepad higher up in the Association list chain [if there is such a thing] or b) delete IE as an association with .txt files altogether [who wants to open text files with IE]? Anyways, a few ideas around this mystery.

    Unfortunately I don't have the resources to dig into this so hopefully someone out there will confirm or deny this and share with the rest of the class. Any takers or am I completely off my rocker here?

  • Calgary MVPs

    2 Comments

    Just a quickie for those that are feeling the global warming in our fine city (-30 to +6 in a few days, that's Calgary for you). In Calgary we currently have 6, count them, 6 MVPS. Here's the rundown:

    Blake McNeill (Windows Security)
    Jason Dunn (Mobile Devices)
    Daniel Mitchell (Exchange)
    Daniel Carbajal (C#)
    Bil Simser (SharePoint Portal Server)
    John Bristowe (ASP.NET)

    The last guy is a bit shady and I suspect really only knows about Microsoft Bob but I've included him here for completeness (actually he's the Microsoft Regional Director around here and a great guy but I have to get my digs in).

  • ASP.NET Whidbey Web Parts Framework

    No Comments

    As I get ready to introduce Visual Studio 2005, .NET 2.0 and a raft of other things to our organization (no easy feat), I'm spending more time focusing on the Web Parts Framework that .NET 2.0 has to offer and how it will empower your web developers with things that were done with gobs of coding in the past. Personalization, customization, and all that good stuff that we're used to in SharePoint can now be put in the hands of any ASP.NET developer. It's really powerful stuff and will help get us to a common framwork no matter what the application content is.

    Nikhil Kothari, a development lead on the ASP.NET team at Micrsoft, has an excellent post here on his blog about connectiing Web Parts together and provides a nice sample that hooks up a calendar with it's entries. No SharePoint needed (but the 20 .NET framework is). Also check out his article for an Introduction to Web Parts here on MSDN which gets non-SharePoint developers feet wet with what's coming and how this is going to change the way you think (and develop) ASP.NET apps.

    As we SharePoint developers know (and those using SharePoint), Web Parts are the cat's meow when it comes to cutomization and personalization so armed with that, you can really empower your web-based application users with powerful capabilities for next to nothing in development.

  • Merging and Managing Documents and SharePoint

    1 Comment

    So here I was trying to figure out some ways to manage mutiple parts of documents stored in SharePoint and Word, IE, SharePoint, or some combination of the above are all behaving badly and causing me (and from the newsgroups, others) grief. After many cokes and munchies, I've updated the blog with some ideas around how to do this without shooting yourself in the head (and the gotchas I went through to discover this).

    The problem is to store say 10 (or some number) of different documents (potentially from different document libraries) in SharePoint and:

    1. Allow users to edit the various individual documents AND (here's the kicker)
    2. Send out a compilation of all of these documents into a single one AND (now it gets ever better kids)
    3. Track the changes made by someone external to document AND (final nail in the coffin)
    4. Merge the changes back into SharePoint (from say a copy of the document you sent out that came back as an email attachement).

    Okay, besides having lots of ANDs there are a few challenges here. Some are easy to solve, and some that are driving me batty.

    Problem #1. Store a number of different documents in the system, allow people to edit them, track changes, all that good stuff. Easy sleazy. Document library + Document + Word 2003 = Bob's your uncle. Boy, if only my job was this easy.

    Problem #2. Create a compilation of these documents into a single document and send them to someone for editing. Okay, not too much of a biggie. Lots of ways to create a compound document. This KB Article says to not useWord's Master Document feature with SharePoint. They're just not compatible. The work-around is to use the RD or INCLUDETEXT fields. There's a great article by Dian Chapman (I have a lot of respect for anyone who puts Bill Gates on their resume as a reference) here on how to use this. It took me a few minutes to realize the RD field (reference document) wasn't going to pull in my sub-documents but rather be a facility to create an uber table of contents across all of them. The INCLUDETEXT field lets you specify a URL to a document and will basically pull the contents in with some nice options (formatting is always a problem with lots of different sources). Since all documents in SharePoint are URL addressable, I was all set. It creates what looks like to a user a single document in a document library. Click on it and it launches Word with all your documents brought together. Nice. Great. Bundling it to send out is a bit of challenge since this is compound document is just directives to include the other documents. The actual document will try to retrieve the others, which is great if you have access to them but we need to create a real 500 page (or however big it is) document to send to someone externally. In any case, the document can be exported or something to create this.

    Like I said, this compound document isn't a document at all. It's just that original document you create with the INCLUDETEXT fields to go retrieve each sub-document. While it looks like a single document, it isn't but you can change this single document as if you're editing any regular document in a document library (no special codes or anything). Oh wait. Gotcha. Here's an image showing the setup:

    What the heck is going on here?

    So I open the compound document (indicated by A above), go down to page 50 (which happens to really be document B in Document Library 2), and merrily change the contents. Click File | Save and the typical Save dialog comes up (SharePoint aware). Any meta data on the document library will popup so I can enter this. Fantastic. However since the compound document isn't a copy of all my sub-documents, the changes must have been made in Document Library 2 right? Nope. Open the compound document again. Yup, the changes are there. Check the sub-document. Nothing. Flush the IE cache. Nope. 

    In the picture above, the compound document is A which looks something like this:

    {INCLUDETEXT "http://servername/sites/sitename/document%20library%201/doc1.doc" \* MERGEFORMAT}
    {INCLUDETEXT "http://servername/sites/sitename/document%20library%202/doc2.doc" \* MERGEFORMAT}

    One of the sub-documents is B which is what is being edited in the scenario above. However the B document doesn't get updated. For those that are still awake and keeping score:

    • Edit A (the compound document). B (one of the individual documents) is not updated.
    • Edit B. A shows the changes.

    Remember, A is just 2 fields pointing to other documents. There's really nothing to edit there. Editing B will show the changes in the compiled document but only after you do a Select All then Update Field (F9). Otherwise, A will continue to show that last time the fields were updated (took me a few coffees to get that straight this morning).

    Problem #3: Track the changes made by an external party. A couple of options here as Word has (and has had for awhile) a Track Changes option. You can password protect this option, but it's not hard to get past that. If you really want to secure the contents you need to drop in a Rights Management server and protect the document this way. Note: You'll need to expose your DRM server externally if you send a document out that has the contents protected and there's a whole bunch of things that have to be done with this (end users needing Office 2003, etc.) so it will take more than a click of a button to enable it but it's pretty slick overall once you get the infrastructure and processes in place.

    Anyways, without tracking changes (or not trusting if someone can bypass it as the other end) it's not too difficult if you keep a copy of the fully merged document you sent out. Word 2003 has some nice Compare features to show you what's changed no matter what options were enabled, overridden, etc. Again a caveat here is that you actually have to unprotect a document (if it's protected) before you can compare one document with another.

    Problem #4: Merge the changes back into the copies of the documents in the document libraries. And here's the rub. If you send the document out as a single (new) merged document, even with the ability to see where the changes happeed, how do you get any changes back into the various bits and pieces that made this thing up in the first place (without having your users jump through hoops editing large numbers of sub-documents individually).

    So, bottom line...

    1. You can use a compound document with SharePoint however you need to use the RD and/or INCLUDETEXT tags and not the Master Document feature of Word (see KB article above)
    2. Do not edit the compound document directly, instead edit it's parts and regenerate/update the compound view.
    3. If you have to send a compound document to an external editor, send them the parts and perhaps a read-only copy of the compiled set of documents (like a PDF). You won't be able to merge the compiled document into the individual parts

    Clear as mud now?

    Note: I keep reading this and parts of it still doesn't make sense, however I do think there might be value in putting together a coherent post/article on "How to Support Compound Documents in SharePoint" or something. Watch for this in a couple of days. We'll just pretend I was having a bad morning.

  • I am the king nerd god!

    No Comments

    After watching my refridgerator die a horrible death (along with it's precious cargo [goodbye pork chops!] and the 3 hour cleanup I had afterwards), I needed a diversion. Thanks to Bruce Johnson, I killed a few brain cells and discovered that I was 97% nerdier than everyone else. Okay, so not everyone else, but those that took the test. Nope, no cheating.

    I am nerdier than 97% of all people. Are you nerdier? Click here to find out!  

    I'm not sure if I should be happy or sad?

  • Making SharePoint easier with NAnt

    No Comments

    I came across Mads Nissen and his blog about using NAnt with SharePoint. I've been using NAnt for a couple of years now for Continuous Integration and automated builds of .NET projects. While MSBuild promises to come along and do all of what NAnt does (and more), it's awhile off and requires the 2.0 Framework (although there is a MSBuild Compatibility Toolkit) so for now NAnt is a nice substitute.

    The idea of adding tasks to NAnt to support SharePoint just gets me all giddy (doesn't take much does it?). Deploying web parts, doing Enterprise deployments of portals or multiple team site creation through a NAnt task sounds great. While SharePoint templates are great, they only address half the solution. You still normally have to go in and setup security (even with custom site definitions) and if there's any special customization to be done (like corporate branding or maybe adding web parts dynamically to sites based on content) then it's usually a day or so of tweaking and changing things, settings up site groups, etc. All could be nicely done by a set of NAnt tasks and even better a nice rollout task for those deployments that go sour and your environment management people want to know how long it will take to undo what you've done.

    So if you're a SharePoint developer or someone interested in getting into SharePoint and using NAnt, please check out the GotDotNet Workspace setup by Kris Syverstad and join in the fun. Thanks to Mads for getting me hooked up on this too!

  • SharePoint meet PHP. PHP meet SharePoint

    2 Comments

    So here I was, wanting to update my personal site, bilsimser.org, and give it some new features (especially after being hounded by a certain someone at work who shall remain nameless...). The problem was that my web host only provided PHP and MySQL based sites. I would prefer a .NET or even SharePoint site but I'm also a cheap-skate and like the rates I get now with my provider. Maintaining a website with lots of static content (like what I had) was so 2004 now and I didn't want to code my own PHP portal or content management system.

    I had played with PHP-Nuke a long time ago and read-up on how you can completely change the look and feel to the site with it's theming capabilities. PHP-Nuke had a lot of nice features out-of-the-box that appealed to me like full searching across the site, downloads, links, announcements, etc. Hmmm, sounds very much like SharePoint. All the kind of stuff I didn't want to bother maintaining with static pages. I began to think about the whole PHP-Nuke themes and thought, "how close can I get it to looking like SharePoint without changing the codebase?". This is the result so if you do a double take on the site, it's all PHP powered with no .NET in sight.

    PHP-Nuke bears a lot of resemblance to SharePoint (I guess all "portal" type software does, or maybe it's the other way around). The modules would make a good Quick Launch. Blocks seemed to have a Web Part feel to them. Search was there. All it needed was a visual overhaul and a few tweaks. After dissecting SharePoint for awhile and the DHTML it spits out, I grabbed some of the graphics and stylesheets from a default install of WSS and started on the new Nuke theme. A few days later, lots of tweaking of tables and pixels and telling PHP-Nuke all about these imaginary "ms-" classes, and my SharePoint theme was born for PHP-Nuke.

    I still have some work to do. Namely the modules list isn't quite right but it's close to SharePoints own Quick Launch and there are no dynamic menus to hide/show Nuke blocks (think Web Parts) like you can with SharePoint. I did track down some mods and add-ins that I'm trying out and I think I can get the Quick Launch menu 100% there and at least add the minimize option to each Nuke-block. Overall I'm pretty impressed at the level of customization achievable with a little PHP coding. There are a few small bits that are not 100% customizable (like the page title has that annoying "-" in it which I can get rid if I slightly alter every page, but I didn't want to touch the Nuke codebase).

    So if you're stuck like I was with running PHP on my webserver, drop by and take a look. You can download the PHP-Nuke SharePoint theme directly from here. Feel free to use it on your own PHP-Nuke site and claim back that SharePoint look and feel we all know and love.