This is the first part of a business video series I’m going to publish to share discussions from some of the world’s most successful entrepreneurs. In this discussion, David Heinemeier Hannson, co-founder of 37signals and the creator of the Ruby on Rails framework gives an uplifting, straightforward talk on creating a profitable company, charging money for your product, and to solve simple problems.

With SharePoint being such a fluid platform it’s easy to extend the capabilities of something like a simple document library to really integrate with your everyday business process. That said, in a media production or design environment many of the file types used just show up as the default “paper” icon. In this article I’ll walk through the process of adding additional document type icons to SharePoint.

Prerequisite: This solution requires access to the physical server and permissions to reboot IIS.

To get started, we need to determine what file types we want to add icons for and as applicable, if there are any default icons definitions that we want to change. As an example, SharePoint uses a generic icon for .png files, but I’d really like the Fireworks icon to be used, so we’ll need to change the default definition for that type. Once we’ve determined what icons we need, we need to gather those icons and make 16px square GIF files for each one. SharePoint’s naming lexicon uses icXXX.gif where XXX is the extension of the file type the graphic represents (ie: icbmp.gif for a BMP, icdocx.gif for DOCX).

Once you’ve got your icons put together it’s time to move them to the server and make the necessary changes to the server.

Depending on your SharePoint installation, you’ll work in one of the following paths:
Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Template
Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\60\Template

Inside the parent template folder, you should see a folder called Images, which contains all of the default SharePoint graphics (including the default icXXX.gif files). Drag your new icon graphics into this folder. Once the transfer is finished, we can edit the XML file that ties actual file extensions to a specific icon graphic. Inside the file path above, browse the XML folder and open up DOCICON.XML in your preferred text editor.

In the “ByExtension” section of the XML structure you’ll notice that there’s a mapping definition for each type of file extension. If you want to change the graphic that one of the existing types points to, you can edit it here. For example, .psd files by default use the icbmp.gif graphic, but I want it to show my psd graphic, so I can edit that file reference here.

For new definitions, I prefer to work at the bottom of the file. Some people may prefer to keep them alphabetical, but I like to know which ones I’ve added, so I always make my changes at the bottom. Insert new mappings as shown below for each type you wish to add. Once you’ve finished editing DOCICON.XML, save and close the file.

<Mapping Key=”extension” Value=”icXXX.gif” />

As an example, let’s say we want to add a new entry for PDF files:

<Mapping Key=”pdf” Value=”icpdf.gif” />

All that remains now is to restart IIS on the server in order to allow these changes to take effect. For those of you unfamiliar with this, note that when this happens your server will be inaccessible to your users for a couple minutes.

Click Start -> Run, type in the following command and hit enter:

iisreset /noforce

Note that you can run iisreset without the /noforce switch, however in a production environment /noforce is a nice idea as it prevents the server from abruptly terminating the service if a graceful shutdown fails. Once IIS comes back online, you can access your site and see your new icons.

Before:

After:

I recently found myself searching (to no avail) for information on how the SharePoint list attachment process actually works; it seemed as if there was no documentation or previous experiences available anywhere. In my particular scenario, I needed to be able to produce an auditable list which showed the date/time, filename, and username for every upload, a report which WSS doesn’t offer out of the box.

My solution became the creation of a second list, which would serve as this master record of all uploads. Once I understood how SharePoint actually processes the file attachments, I was able to use a combination of the PreSaveAction function and the jQuery Library for SharePoint Web Services to log each of the file names into my list.

This article isn’t meant to address the complete breadth of capability, but more to offer the technical ins and outs. I should point out that for the purposes of the article I’m making the assumption that you’re working on the default NewForm.aspx or EditForm.aspx forms. While I would imagine the document model and process is very similar for custom list forms, I have yet to dive into that world.

Where is the attachment form?
You may (or may not) be surprised to learn that the attach file form actually exists right inside your stock list form. The following graphic breaks out the overall form structure—more on the details in a minute. For the purpose of this article I’ve created a test list with 4 fields.

1. All of the list fields and their submit buttons exist inside a span with an ID of “part1”.
2. The “idAttachmentsTable” is populated dynamically to display the paths, names, and delete icon for each attachment.
3. The file fields and related submit buttons exist inside a span with an ID of “partAttachment”. This is hidden by default so it is not viewed when the form is initially opened.
4. The “attachmentsOnClient” table contains all of the file fields for the form. The contents of this table are always hidden to the user.

Clicking the “Attach File” link at the top of the form calls a JavaScript function that has two tasks. First and foremost it checks to make sure that the form structure (sections 1 and 3) exist. Assuming that check passes it then hides section 1, reveals section 3, and sets the focus to the active file field—creating an illusion to the end user of a new form loading.

What actually happens when I attach a file?
When you select a file for attachment and click OK, you’re not actually sending the files to the server yet. SharePoint keeps track of all of your changes to the list fields, attachment of files, deletion of files, etc., then waits until you save the overall list entry to transfer any new files to the server.

SharePoint manages a numerical variable called “FileUploadIndex” which it uses to keep track of how many attachments you have, and ultimately translates into the names of the file fields that you interact with to supply your attachments. The ID for each file field becomes “fileupload” concatenated with the current “FileUploadIndex” (ie: “fileupload0”). I’ll point out now that Microsoft is very inconsistent with field and variable lexicon here; sometimes they use “FileUpload” and other times it’s “Fileupload”, etc.

When you click the OK button to attach your file, SharePoint calls the “OKAttach” function that performs the following tasks:

1. First it creates a new row in Section 2 containing the file path and the link to delete the file, should you wish to suddenly change your mind.
2. Next it hides the file field you used to select your file, creating the illusion that it now sits inside Section 4.
3. Thirdly it creates a new file field inside Section 3 incrementing 1 to the “FileUploadIndex”. So for example, if you had just uploaded your first file (fileupload0), this step would create a new file field inside Section 3 called fileupload1.
4. Finally, it hides Section 3 in its entirety and displays Section 1, creating the illusion that the other form has now loaded again.

Should you now choose to click “Attach” again to add another file, you’ll actually be populating the new field (ie: “fileupload1”) created in step 3, and the process repeats. When the attach form is displayed for your next file, only the active field (essentially the one with the highest index) is displayed, while all

others are hidden inside Section 4.

So what does this get me?
Let’s say for example we wanted to check file extensions to prevent certain file types from being uploaded, or possibly make a web service call to see if documents with the same name have already been added to a document library or another list. In my particular use, I was making a web service call to log the names of the files in another list. Due to the fact that SharePoint names the file fields with a constant prefix, we can access those fields and run our own script or validation against them.

You can either use straight JavaScript or jQuery to access the file fields. In my particular case I had already loaded jQuery so it makes sense to utilize that method. The following example code loops though all fields that have a name starting with “fileupload”, outputting the full local path and filename.

<script type="text/javascript">
  function PreSaveAction() {
    $("input[name^='fileupload']").each(function() {
      if ($(this).val() != "") {
        alert($(this).val());
      }
    });
  }
</script>

You’ll notice that I’ve placed my alert inside an “if” statement that checks to make sure the value isn’t “nothing”. Remember that step 3 of the OKAttach call creates a new file field ready to accept the next file. As a result of this, there will always be a file field on the form that has no file in it. Obviously when you’re processing the files you don’t want to be bothered with blank rows, so a simple check to make sure the value isn’t blank, or the length of the string is greater than zero will suffice here.

If you wanted to record the file name to another list, like in my application, you can utilize the jQuery Library for SharePoint Web Services to call the UpdateListItems operation of the Lists web service and record $(this).val() into your list.

Conclusion
My particular scenario concluded with accessing the file names the user had selected, utilizing PreSaveAction to call the UpdateListItems web service and log the selected names to another list. That said, the true potential of understanding the process surrounding list attachment process is to couple it with the attachment deletion process. In my next article, we will explore how SharePoint tackles deleting files within the form and how to integrate the two processes to prevent people from uploading file types that you specify.

You may remember reading my post from a few weeks called jQuery Introduction, where I mentioned my new discovery of this incredibly powerful library and discussed some very basic uses of it.

At the end of the day, when the rubber meets the road, jQuery is an incredibly powerful library, which has its uses far beyond pop-up windows and quirky little effects that most professional designers agree are better left out. The practical uses include the execution of web services (also mentioned in my initial article), data and content delivery, and user experience enhancements (to things such as forms) that add value in the eyes of the end user.

There’s been a lot of discussion lately across Twitter and on several blogs about the efficiency of jQuery. jQuery is JavaScript, and JavaScript add’s overhead–that isn’t being debated. Marc (who I have great respect for) has stood up in defense of the library, and rightfully so. There’s been a lot of discussion on his blog (Putting the Brakes on SharePoint with jQuery – Or Not, and Putting the Brakes on SharePoint with jQuery – Or Not (Some More)) regarding the issue, but as opposed to clogging up his comments too much, here’s my general thoughts on the issue.

Marc hit the nail on the head when he said that “[as] developers, we owe it to our clients to do things as efficiently as we can given the tools at our disposal.” This is the main point in this whole debate over the practicality of jQuery. People, “developers”, are using it in inefficient ways. Blaming improper and inefficient use of the library on the library itself is a bit like yelling at the airline because it snowed and your flight got canceled. It’s not their fault, but it makes you feel better and gives you an outlet to point blame at. In this case, the only people to blame are the people who call themselves “developers” but lack the acumen to develop efficiently. jQuery is easy to integrate, no question there; its ease of use (in basic applications) is putting it in reach of people that maybe shouldn’t be using it (in my opinion).

One example that’s been floating around was using jQuery to change the alernating shade color on a SharePoint list. Using jQuery to find every row in a table and manually append a “style” tag to it with a background color is just obserd–and this is a perfect example of what we’re talking about here. To the “developer”, it’s a 2 line jQuery call, but on execution it’s applying that 2 line call to every row in your table. On the flip side, you could use 2 lines of CSS to rewrite the class of the row and be done; no redundant processing, significantly less overhead–the practical way. The “developer” should know that.

So how much additional overhead do these techniques add to SharePoint and other web applications? Is that overhead value add, or a complete waste of resources? Again, it’s the job of the developer to make things efficient, but at the end of the day you have to consider the usability as well as the performance. Is adding a library of 17 lines of minified JavaScript going to really burden my load time? Granted that’s a bad measure because it’s not the presence of the library, but rather how you use it–but at the end of the day, if the inclusion of that library adds a few miliseconds to my load time but increases the usability and user experience with forms or content delivery, I think that’s a valid trade off. Do we need to use every bit of RAM and network bandwidth available, no, but we’re also a high-speed world now. Gone are the days of dialup (for the most part), and technologies, methods and techniques that were unreachable just 5-10 years ago now are. Everything costs something–that dynamic form, that clean login box, that chromeless window–they all cost overhead, resources, money, but it’s up to you to implement the functionality you want in a way that performs to the satisfaction of your clients; and poor execution by the developer doesn’t mean the library is flawed, overused, or inefficnent.

If you’re anything like me, you spend the vast majority of your day sitting in front of a computer monitor. Most people make those subtle changes to the appearance of their system to make the task of sitting there a little more enjoyable, others do it to make their user experience more efficient, and others just do it for the hell of it. I’ve always used Object Dock to keep my most frequently used icons up in the top of the screen; my personal preference for keeping everything easy to get to.

I’m always on the lookout for new dock icons, but find that it’s very difficult to find matching icons for all of the applications I use. There’s always nice matching ones available for Adobe products, but it’s nearly impossible to find matching icons for other applications. I took it upon myself to make my own dock icon set this evening, playing off of Adobe’s “elemental” style. From left to right: Dreamweaver, Fireworks, Flash, Illustrator, InDesign, After Effects, Photoshop, iTunes, Notepad, Firefox, Thunderbird, SharePoint Designer.

So I was at work last week when one of my colleagues came over and asked about the ability to make a dynamic tag cloud in SharePoint. We had collected a bunch of ideas from the workforce and they wanted an intuitive way to display them all in a dynamic fashion. My first thoughts were of the cumulus Wordpress plugin that I use here on my blog, and after turning to trusty Google I discovered that I wasn’t the only one who had this idea. We based our work off of this blog post, with of course a few tweaks of our own.

This of course emphasizes my points of the usefulness of and my discovery of jQuery as it uses some simple jQuery to access the SharePoint list data. We made our integration a bit cleaner by utilizing the jQuery Library for SharePoint Web Services. We also used jQuery to fade the screen and display the tag cloud in a “floating” popup over the page content so we could keep it nice and big, positioned on top of the SharePoint page.

Show of hands, who knows about jQuery?

I’m willing to bet that if you’re in the IT or web world, you’ve heard the name thrown around. Whether or not in the context of AJAX it doesn’t really matter–but how often do you just skip over the topic and not really give it a thought? Until a few months ago I hadn’t really paid much attention to jQuery, or the implementation of AJAX in my work. I’d used it a few times, and call me old fashioned, but the platform I was working on worked just fine, met customer expectations and performed well. This was until I started following a few key people on Twitter, who I now blame for my obsession of trying to introduce jQuery in everything I do.

So what is jQuery? Simply put it’s a web application framework written in JavaScript that enables rich manipulation of HTML. Odds are that every single one of you has in someway touched jQuery on a website; be it through dynamic styling, form validation, chromeless popups, or rich data interactivity. Everything from that slick drag-and-drop capability for ordering your Netflix queue to the vast majority of Facebook interactivity is all possible with the use of jQuery.

jQuery Integration

Now fast forward past the initial discovery of the real power of jQuery; how do you practically integrate it into your platform? It’s one thing to see the potential, and quite another to make that integration clean and functional. There’s some great jQuery plugins available, and while you may have heard of some of the big ones (prototype, draggable, etc.) there’s literally hundreds out there. jQuery offers a UI library that includes a host of useful user interface elements, and when you want to take your platform to the next level, Marc Anderson has written a jQuery library for Windows SharePoint Services that easily enables rich data features such as cascading drop-downs, manipulation of lookup fields, and dynamic use of the SharePoint web services. Admittedly (credit where credit is due), I fully blame Marc for my new found obsession with jQuery.

Last week I traded in my 2007 MkV GTI for a 2010 Wolfsburg Edition Jetta. Today was a very abnormal mid-November Sunday with temperatures in the region of 70 degrees so it seemed like a great time to give it a wax and take a couple pictures.