I was working on a small, single page/single web part, application the other day and solving an old problem was essential to making the application usable.
How does one do multiple file uploads with a single file technology?
With out-of-the-box, ASP.NET applications (up to FX 3.5), you pretty quickly realize that the state-less world of web application pages is going to make solving a problem like this considerably more difficult. There are of course many 3rd party controls to choose from that solve this problem, and a few of them are visually beautiful, intuitive to use, and elegant in the way in which page developers make use of them. There are also several core ASP.NET features that have come along to help you and this is all good.
However, when SharePoint is your platform layer, you have the advantage of built-in persistence at your disposal. One might even argue that SharePoint applications are not, or need not be, state-less at all. For example, how would Workflow fare without persistence?
So a solution to a problem like this is pretty easy in our realm. You simply need two things; a postback handler and a document library dedicated to caching uploaded files.
The document library is nothing special. In fact, each time I have implemented this part of an overall solution, I have used the default document library settings to create my “file cache”.
The postback handler is something I almost always use. In WSS 2.0, event handlers were less than reliable, and our team avoided them completely in practice. In WSS 3.0, the situation improved quite a bit. However, postback handling code has several advantages during debug.
To be clear, what I am calling a postback handler, is a nothing more than a dedicated helper method in your web part class that performs parsing and inspection of the HTTP response header. Specifically, the form variables returned on postback.
This postback handler will do at least one thing for you; it will know each time the FileUpload control has been used to upload a client file through the MIME multipart/form-data option (RFC 1867) of an HTTP Post and therefore it can store that file (byte or Stream) in your cache doclib.
You will also need a way to keep track of your “list” of uploaded files that are now sitting in your file cache along with every other file that’s ever passed through your web part. There are three pretty easy solutions to this part of the implementation. One approach is to define a column in your file cache that serves as a way to “label” files so they can be associated with one another. Another option, and one I often use, is to define a Hidden control and render it on your page. If you do a View Source on any SharePoint page, you will notice that Microsoft has used this approach a number of times. Lastly, you can also add a folder to your file cache for every “group” of uploads your users do. This folder can be named using a GUID or just text, but obviously it will need to be something meaningful in the context of your application.
Now, the reasons you need multiple file uploading at all are going to vary. For example, if you are going to compress these files into a gzip archive, wrap the archive with properties and store it in a document library dedicated to such a purpose, you will want an easy way for users to accomplish this.
Placing several FileUpload controls on the page is hardly elegant and completely unneccesary in a SharePoint web part application.