January 2006 - Posts

• SuperGeek Tip: Calculate "Full Name" on the client-side AND use it in lookups!

  I mention in just about every Bootcamp that the biggest problem with calculated fields is that you can't use them in lookups.  Well, the solution, as I mention in class, is to perform your calculations on the client-side.  What I don't mention in class (it's a “SuperGeek Moment”, so it's meant to get the gears turning) is the actual code.  Thus I have decided that I'm going to try and write a weekly “SuperGeek Tip”.  This week's tip: Calculating “Full Name” using client-side script, so SharePoint is blissfully unaware that Full Name is anything but a plain text field. At the bottom of the NewForm.aspx and EditForm.aspx for any default Contacts list, just above the closing </body> element, add this code:  <script>   var lastName = document.getElementById("urn:schemas-microsoft-com:office:office#Title")   var firstName = document.getElementById("urn:schemas-microsoft-com:office:office#FirstName");   var fullName = document.getElementById("urn:schemas-microsoft-com:office:office#FullName");   lastName.onchange = fixFullName;   firstName.onchange = fixFullName;      function fixFullName() {    fullName.value = firstName.value + " " + lastName.value;   }     </script>  You can do this in FrontPage 2003, or you could modify the list definition files yourself (the so-called “Ghosted” template -- be aware, Microsoft doesn't support you touching those files if you've already deployed sites based on that site definition). Once you've done this, adding contacts / editing contacts will both cause Full Name to calculate whenever the values of First Name or Last Name change.  Pretty handy, no? Posted Jan 30 2006, 04:45 PM by Dustin Miller with 5 comment(s)

• Document Libraries and Subfolders: Why it's a bad idea

  I'm often asked during a class questions like, “how should I do this,” or, “how do I handle this scenario.”  One of the most common is, “should I use subfolders in my document libraries, separate document libraries, or custom fields to categorize documents?” My answer is always the same, and has never wavered.  Don't use subfolders.  Of course, that goes hand-in-hand with another of my lessons, “don't use the Explorer View,” but that's a topic for another blog post.  Separate document libraries are useful if you need separate security permission sets for a grouping of documents (since we don't have item-level or folder-level security in document libraries with the current release of SharePoint Products and Technologies), but for categorization within a site, nothing tops custom fields. Why am I so against the use of subfolders?  Well, here's the #1 reason: It's not (meta)data.  A subfolder is a location, that's all.  If I had a document's “DispForm.aspx” open on my screen, and I wondered what category the document falls under, I wouldn't think to look at the URL.  I'd look for a field called “Category”.  If it's financial information for Q1/2005, I'd look for Year and Quarter as custom fields, not a subfolder called “2005Q1”. When a document library for, say, financial spreadsheets is created, my first thought is about metadata.  What metadata is important?  Quarter and Year come to mind first, so I'll add two fields called “Quarter” (make it a choice field) and “Year”.  How about contracts written for clients?  Instead of creating a subfolder for each client, I'd add a field called “Related Client”, and make it a lookup to another SharePoint list called “Clients”.  Then, and here's the kicker: I can use web part connections in a meaningful way.  Click on a client, see their documents.  I can't use web part connections in any useful fashion if the target document library uses subfolders to categorize content.  With custom fields, my document library becomes more than a dumping ground for .DOC files, it becomes a valuable collection of (meta)data, one that can be mined, filtered, grouped and viewed in any way I need. If users miss the idea of subfolders, why not group the view of documents by one of those custom fields (or even by two of them, like Year and Quarter).  It looks and feels like an Explorer-style treeview of your document library, and web part connections can be used to further filter the display.  Actually, in my opinion, that “group by” view is much nicer looking than the default views used to show documents in subfolders.  Certainly much more useable. I can hear the anguished cries now: “But my users will need to enter a category, where before they could just drop it in the correct subfolder!”  Make the field required; when they save from Word, they're required to select the category.  If they upload with their browser, you got it, they're required to select the category.  A little user education goes a long way. I'm really interested in feedback on this one.  What do you do when faced with subfolders?   Update: Bil Simser tosses out a few more thoughts on the subject. (Wonder why I didn't get a trackback from his reference to this post?  And this update didn't add a trackback to his post.  Hrm...) Posted Jan 03 2006, 02:49 PM by Dustin Miller with 15 comment(s)