Choosing the Right InfoPath, Part 2

Designing the Right Solution with InfoPath

In Part 1, I discussed the major pro’s and con’s I encountered with InfoPath web forms.  In Part 2, I’ll discuss the basic pattern I see when providing a good design for InfoPath solutions.

Form Design Considerations

When building out your forms, consider the following in order listed below:

BEFORE BEGINNING – read this article on designing for InfoPath performance.  This really is critical as there are so many performance pitfalls with InfoPath 2007.  Additionally, check out this article on developing tips with SharePoint – this is a huge time saver.

1.  Fields – looks for fields you can group.  As forms evolve, behavior is easy to change, fields are NOT.

2.  Visual Layout – use shading and sections for users to quickly identify areas of the form.  For SP2010, utilize themes for possible sync with SharePoint.

3.  Logic – keep it simple.  Be mindful to keep the “spaghetti logic” to a minimum.  Your future self will thank you!

4.  Data Connections – Watch large result sets as paging is non-existant.  If you sneeze, you’ll cause a post-back.  Keep your viewstate small.

5.  Behavior – Use conditional formatting and validation where possible.  Remember there are no pop-up boxes and limited JavaScript support.

6.  Deployment – Package forms in WSPs and use externalized data connections.  You can then change the url in the WSPs and deploy versus republishing forms for each environment (dev, staging, production).  Use Central Admin deployments – do not publish directly to the form library (see previous blog for reasons).

Architectural Considerations

Keeping these four areas in mind and avoiding doing too much in the InfoPath form itself will go a long ways in keeping costs and time-to-production down.

Presentation: Think of the “Form” as a way to present data and provide a means of printing. Keep the form simple and avoid code behinds for as long as possible.

Data Store: Think of the “Form + Form Library” as your typical application database. Utilize content types for backwards compatibility and versioning.

User Edits: For complex solutions, use the “XMLFormViewer + ASP.NET” to edit the form’s data. DO NOT RELY ON THE INFOPATH WEBFORM. This will enable you to use JavaScript, AJAX and whatever other web technology you’d like to incorporate. It will also enable debugging and logging.

  • You will need to parse the InfoPath xml to provide updates.  Remember to add SharePoint checkin/out logic when parsing the xml.  Create a custom content type for hooking in your “XMLFormViewer + ASP.NET” form.  Use a feature activation event to set the EditItemUrl on a custom content type to map the url to your ASP.NET form.  You can then deploy the custom content type to a task list and redirect task edits to a custom ASP.NET form.

Orchestration: Use Workflow (I like Nintex) for orchestrating user/system interaction.

I know there are lots of examples in calling Web Services and etc from within InfoPath.  My experience has been, however, that I spend more time designing around limitations of InfoPath as the complexity increases.  InfoPath is NOT intended to be an ASP.NET replacement and doesn’t even come close to providing the UI scalability and customizations.  Keeping the form simple and creatively leveraging/integrating other technologies will make your travels along the InfoPath much more pleasant!

Advertisements

~ by spninjablog on December 1, 2009.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

 
%d bloggers like this: