Choosing the Right InfoPath, Part 1

I’ve recently been heads down in integrating InfoPath 2007 web forms into SharePoint 2007. Here I try to surface the design guidelines and major “GOTCHAS” that cost me many a night and weekend. In Part 1, I’ll discuss the major pro’s and con’s with InfoPath web forms.  In Part 2, I’ll show a basic pattern for orchestrating solutions with InfoPath.

InfoPath Coolness

First lets do a brief take on why InfoPath is a real contender in the collaboration and workflow world.

1. Printing!! By far the best feature of InfoPath web forms is the ability to print forms right out of box.  Very useful and powerful feature given that capturing business processes in forms often involves printing the form.

2. Look and Feel. No CSS skills required.  Just an intuition for borders and shading – I know, that’s pushing it for me too.

3. Conditional Formatting/Rules.  Power users can utilize Excel-like functions to constrain, hide and validate fields.
Although, I consider this a CON as well – it can lead to spaghetti logic very quickly.

4. SharePoint Integration.  With no-code solutions, integration with SharePoint lists and libraries is very powerful.  Mashups with content types, workflows, versioning can enable rapid automation of business processes.

5. Data Portability. XML data is stored in the .xsn package.  You can then port it around.

6. External Data Sources. Pulling in data from a SharePoint List for example is a breeze to setup.

7. Deployment Speed.  Hands down, you’ll have the ASPX developers beat on simple forms.  Key word = SIMPLE.  I explain below.

InfoPath Hangups!

1. Limited Web Development Features

The most common theme you’ll run into with InfoPath is that the fat-client rocks and the web form features are severely limiting. Therefore, be prepared to create forms that resemble the .NET 1.0 era versus your high speed, AJAX enabled, JavaScript-tricked-out apps. Here is a short list of areas I found most lacking:

– No support for multi-level events.  Example, if a user clicks button, a drop down is populated.

– Very annoying post-backs (WANs Beware!).  This is a great article for detailing the performance crippling post-back problem.  Apparently anything from richt-text fields (needed for printing), conditional formatting, view switching, rules, data connections, complex calculations and full moons can cause MULTIPLE expensive post-backs depending on form interaction.  This can be very disorienting resulting in blindness, epileptic seizures or temporary maddness.

– Limited notifications. No popup boxes.  Crap error notifications – dreaded “Form Closed”

– Limited JavaScript support.  You can try the xmlformviewer, but it does not provide near the control or feature richness of an ASP.NET application

– Form url dependencies force republishing per environment (Dev, Staging, Production)

– Issues modifying a “Promoted Field” using the SharePoint list object model.  This may have been content type related but for certain promoted fields, it would not let me update the value.  However the same code logic would work on other promoted fields.  I spent a couple nights on this and after confirming some others in community were having this issue, I finally gave up and wrote an XML parser for modifications against the form data.  UG!

– The contact selector is a riot!  No property promotion support.  Unintuitive to setup.  AWFUL post-backs.  Good luck restricting it to one user – you can try this hack if you’re brave.

Bottom Line:  If you expect to do some validation customizations or feature rich user experience, look at ASP.NET.  Additionally, post-backs can significantly hinder user experience over WANs.

2. Code-Behinds Introduce Whole New Pain

If you cross the great chasm to creating form code-behinds, you should proceed very carefully – and multiply your estimates by two.  Here’s a summary of the steps you must now take to deploy your forms:

  • Enable InfoPath 2007 VSTA feature for compiling your code
  • Publish the form to a network location
  • Upload the form via Central Administration (wait for App Pools to refresh)
  • Activate the feature at the Site Collection level
  • Associate the created content type to the list or library

That’s 4 more steps then if you chose not to have the code behind.  The waiting for the App Pool refreshes in Central Admin and main web application can become VERY time consuming.  Additionally you should consider:

  • “Attach to Process” does not exist in VSTA – therefore no InfoPath debugging
  • Quick-Find in VSTA will not find items in minimized code blocks.
  • Content Type Weirdness. Because your form is a content type, you may run into column duplication on deployment.  My last deployment, I had a content type that insisted on creating a brand new column called “Product” when one in the library already existed.  If you chose the “no-code” solution, you have to option to map the columns and this is not an issue.  A friend of mine found a GREAT workaround here if you need to fix this.
  • If you promote another field to an existing InfoPath content type, you have to reactivate the form feature for field to be pushed down.  This is a common problem with Content Types.
  • For the contact selector, you may not utilize the “AccountId” as a promoted property.  Instead you have to use custom code.  Mapping fields with code-behinds are obviously very problematic.

3. 64 Bit Mayhem

If your clients utilize a 64 bit OS, you may be in for some PAIN.  Even though IE8 32 bit is the “default”, I’ve had email kick open the 64bit IE 8 which is VERY unreliable for displaying InfoPath 2007.  You may want to drop InfoPath all together or find a way to ONLY have the 32bit IE 8 open.  I’ve had so many problems with 64bit clients displaying InfoPath web forms.  The most common error usually occurs at random when using rich text fields and contact selectors.  The entire form locks and a warning appears stating “Stylesheet object not found”.

4.  Breaks the rules on Check-In/Out

If Tom checks out the form and then Jane subsequently opens the form, a number of things do NOT happen:

  • Jane does NOT get notified that the document has been checked out
  • The form is NOT locked into readonly mode
  • After spending 30 minutes editing the form, Jane clicks save and is presented with an error NOT indicating the checkout problem
  • Jane is NOT happy!!
  • Good reference.

5.   Beware of session bloat.

Session bloat can be caused from attachment controls (files & pictures).  The session for non-xmlviewerforms is stored in SQL.  Therefore with attachments this can wreak havoc on your WFE-SQL communication as the session is rehydrated on each post-back.  Also, attachments get stored as Base64 blobs right in the xml.  This may result in Out of Memory errors (even for file sizes as small as 3MB) as the parser barfs.   Use links to doc libs instead or a custom control that stores files in SharePoint.  Good article on session.


~ by spninjablog on December 1, 2009.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: