InfoPathology - Part 1 - Introduction

InfoPathology is, literally, the study of InfoPath. Now although I made this word up, it defines exactly what this series of blogs intends to do: help people understand InfoPath, and study it in different ways. Part 1 is an introduction to the technology, and the niche it fills in the development world. But before I begin, I have a bit of a disclaimer.

I am not writing these blogs as an expert passing down my experience to new, bright-eyed InfoPath developers hungry for guidance. I am your peer. I’ve been in the trenches with you. I’m simply outlining some of the problems I’ve solved, and the ways I thought about solving them. There are no guarantees that this will be your InfoPath salvation and lead on to a long and happy life with this technology. InfoPath is one of the best tools I’ve ever used, and my hope is that some of the success I’ve discovered (or stumbled upon) can lead you to stumble upon some of your own.

And the battle wages onward: Win Form or Web App? Win Forms have always given us the ability to deliver powerful solutions to our clients. Nothing makes their lives easier than double-clicking a familiar icon on their desktops and launching a custom application that simply does everything they need. These applications live happily on the office intranet, connect to the database or application server sitting in the basement, and perform all the magic capable of the .NET framework.

But what if updates need to be performed? What if users need to work from home? What if different departments begin to need slightly different flavors of the application? As the organization grows, will scalability become an issue? These questions are commonly answered by installing IIS on our server, the latest Internet Explore security patches on our clients, and turning that .EXE desktop icon into an .ASPX home page.

Now wait a minute. Our Windows Application needed to access the user’s registry. That piece won’t work anymore. The interface is more inviting now, but users have commented that working with multiple windows open at once allowed them to use the application more efficiently. Also, when the Internet connection is down, no one can get anything done!

Clearly, Microsoft needed to fill this gap. Enter InfoPath, and the world of smart, rich, thick, thin, connected, and easily distributable clients. One of the first things I realized when I started getting my hands dirty with InfoPath was that a slightly new developmental paradigm would be necessary in order to be successful.

Normally, when starting a new project with a particular technology, be it Win Forms, Web Apps, or really anything else, all I want to know is what is impossible. Tell me where I should build the walls that will house all of the functionality I can possibly, and efficiently, create. Beyond these walls there is nothing but compilation errors, exceptions, dangling requirements, and essentially things the technology just can’t handle.

For example, with ASP, I know that the account I’m running under isn’t always guaranteed to have the permissions to execute the code I may want to write. So I build a wall there, so as not to tempt myself to indulge is some of the tantalizing System.IO namespaces. Or with Windows applications, I know that I can’t achieve the formatting and content organization that HTML can give me. So I erect another wall here, and deal with group boxes and maybe a panel with a different shade of gray for a background color.

But with InfoPath, I quickly found that it was quite difficult to build my comforting walls. I could keep bending the rules to achieve my goals without having to “rig” my applications to work correctly. A wall would go up one day, and then come crashing down the next as I repeated my new InfoPath mantra: “I didn’t think I could do it that way…” I found myself free to roam between the walled off developmental worlds of Win Forms and Web Apps and float above the chasms that separate them. Never before could I come up with more creative and fundamentally easy ways to solve difficult problems.

At the same time, and with a very emphatic however, never have I had to sweat, bleed, and pray harder to solve easy problems. There are so many tiny short comings in the environment that could potentially bring a large enterprise application to its knees if you don’t know how to tiptoe around them.

It took me three weeks to figure out how to get the window’s title to read something other than “Form 1.” I spent over a month trying to programmatically populate specific rows in a table without having to sell my soul to JavaScript. Do you want to stop the “Do you want to save this form?” message box from popping up if the user hits the “X” button on the title bar of a form that’s been modified? I still have nightmares…

What I’m going to show you is how to make InfoPath work. My clients have never heard me say, “No, sorry, we can’t do that in InfoPath.” Win Forms and Web Apps can be easily pushed to leverage some amazing functionality. Although InfoPath might seem like it won’t budge on some things, once you get some momentum going, you can push it as far as you need it to go. My methods will demonstrate how a little “out of the bubble” thinking in regard to InfoPath development will make you want to run back to your old projects and resurrect and deliver all those requirements that had to be disregarded because “the type of forms we used can’t do that.”

There are three major areas of InfoPath I would like to discuss. First of all, there is the code-behind conundrum: when to use managed code behind your form, and when to use built-in InfoPath logic. Next, there is the InfoPath/SharePoint integration solution, and all the wonderful and terrible things involved with it. Finally, there are my InfoPathisims. These are the problems intrinsic to InfoPath that keep you up at night; their solutions, however, make you sleep like a baby.