Hey Shereen, Why don’t you use InfoPath more often in your projects?

To which I often reply, it’s the 80/20 rule. InfoPath doesn’t get me all the way there, and to invest that much time and effort only to hit some project impeding roadblocks is not a conversation I like to have with our clients. It’s not fun, no one enjoys explaining why you CAN’T do something, because when it all boils down, clients are only interested in the solution.

Recently, however, I was given the opportunity to work with InfoPath again, and it’s reminded me in many ways, the pros and cons of using this tool. So I’ve jotted some notes down, and I’ll share with the rest of you, and if we can have a constructive, intelligent debate about this, I’m all for it. Keep in mind this is InfoPath 2007.

Let’s start with the Pros.

1. It’s incredibly easy to do some basics in InfoPath. Adding controls to a page, validating those controls. Applying conditions that define when to show/hide specific content, or when to display that content in a different way. Tab order, submission and layout are all examples of things we can do well in InfoPath. This is something any power user can do, and probably do well.
2. It makes it possible for power users to maintain a form post-development and well into the future. The same is not true for a custom form or web part built in ASP.NET I don’t care how ‘powerful‘ your users think they are.
3. It’s definitely a bit easier to deal with Lookup columns and People or Group columns in the sense that it takes very little effort to wire them up and save/load from those controls within InfoPath. These are often problematic in standard ASP.NET form development.
4. Repeating tables are great, these take little to no effort to add to the page and give users a lot of flexibility so that they may dynamically add or remove additional rows.

So definitely some good things we can do with InfoPath, however, there are definitely some pitfalls that make you go ‘ARRGHHHH‘!

1. You can’t use a Contact Selector field and publish to a column of type Person or Group, you have to use either a workflow to populate these fields or custom code. A lot of times, we use these fields to power views with the [Me] keyword to display personalized views of the data. This is hard to do when a Contact Selector translates to a Single Line of Text. It also starts to challenge the Ease Of Administration principle I talked about above, because now users have to maintain a workflow or a section of custom code to get past this hurdle.
2. In terms of order and organization of the Data Sources, it sucks. Any field that you create and then remove, does not get removed from the data source (which I understand), and you have to manually manage and maintain your data sources to keep it clean. I can honestly waste a ton of time formatting and moving fields into the appropriate containers and ensuring that overall, the data source stays clean. Maybe I’m just being anal, but it’s not something I particularly enjoy – I do feel it’s necessary though. It can get pretty hard to read if you have a form with 100 fields and you let it get out of control.
3. It’s not easy adding expandable/collapsable regions. If you don’t agree, let’s throw up a challenge where you build out your regions in InfoPath and I’ll do it in html/css/jQuery and we’ll see who finishes first.
4. Repeating tables only save the first row of data, not subsequent rows. So anytime you do use a repeating table, don’t plan on using that information for any views or filters of any kind. Normally though, this isn’t something I find myself needing to do often, but when it does come up, it’s kind of a pain that I can’t do it.
5. Rich text formatting is not supported in browser based forms.
6. There is no way that I know of to add a header and footer. If you’ve got a header or footer and multiple views, any change to those will have to be applied to each view. I’m not positive about this one, but if anyone corrects me on this, I’d be happy to update this post.

Tips

1. When setting up tabbing between sections, it’s wise to setup a break in numbers in case it changes down the road. Otherwise imagine defining your tabbing order and then inserting a field at tab order 10.

So to summarize, I definitely see the power of InfoPath and if I can keep the requirements dead simple, and there’s flexibility when we hit roadblocks, I don’t see why this wouldn’t be the faster approach to form development. I’d probably recommend it.

However, if the reverse is true, and I know there will be business workflow or requirements that will make working with InfoPath a challenge, I’ll opt for the custom web form route, because that guarantees me no limitations to what I can do. And it’s likely faster.

It all comes down to an evaluation of the requirements and the prioritization of features over simplicity and maintainability that will ultimately guide which route I take.

If anyone would like to add to this, or has a suggestion for something I overlooked, ping me here or send me a tweet on twitter. I’m all for finding better and more efficient ways for getting things done.

This form template was deployed as part of the FT-01-f97dd99b-7ea7-1c56-25e5-eddf7ff6099b feature. This form template should be removed only by uninstalling that feature.

Resolution:

stsadm -o uninstallfeature -id idoffeature -force
stsadm -o uninstallfeature -id f97dd99b-7ea7-1c56-25e5-eddf7ff6099 -force

To determine the id, navigate to the

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\FT-01-f97dd99b-7ea7-1c56-25e5-eddf7ff6099b

and locate the feature.xml file. The id will be located inside of this file.

The InfoPath team blog has a great post on becoming a better template administrator:
Behind the Scenes of Administrator-Approved Form Templates