SharePoint Development & Administration + InfoPath

When should code be used in an InfoPath form and when should it be avoided?

There is no simple answer to this question, as it comes down to a matter of personal preference. This article is aimed at reducing the development time for InfoPath forms of various scales. The following are some tips to help you make the right decision.

Firstly, I should note that InfoPath is a great tool for creating electronic forms, as many features are provided to including data connections to external sources (Database, SharePoint, etc.), data validation and conditional formatting which allow complex forms to be created and submitted without using any code.

I my opinion, as an InfoPath form becomes more complex the efficiency of the form's development is reduced when avoiding using code. This is due to the amount of mouse clicking required to set default values, create rules and apply formmating conditions to individual elements in a data source, or controls on the form template. If code is not a strength and you don't mind a bit of clicking, then this probably isn't a bad way to go as it does have a major benefit which is often overlooked: The Logic Inspector. If all, or most form functionality can be created without using code, the Logic Inspector will reflect the amount of detail put into the form's design as well as giving an overview of any functions if code is used. It allows you to see at a glance, as well as print details of any validation, field calculations, rules or programming used accross the entire form.


How can development time and effort be saved when designing InfoPath form which require code?

Code is Reusable
InfoPath form code can be written to allow reuse in multiple forms which may have completely different requirements for functionality and layout. Developing to enable code reuse will prove to be a significant benefit to any developer. Having access to code that you know that works as well as an intermate understanding of how it works will save a many hours of development, as well as providing building blocks for further development.

It will take longer during the initial stages to develop forms using code, but as you gain experience and start build a "bank" of reusable code, development time will significantly decrease.

If developing a set of forms, starting from a common template with the layout and theme already applied to the form can also reduce development time as well as enhance the proffessional apperence of the set of forms.

Choose an appropriate language to become most familure with
Many languages are supported when using InfoPath forms (JScript, VBScript, C#, VB), sometimes making it harder to find relevant information or resources when troubleshooting and learning. Some languages are more powerful than others in the functionality offered, or the ease of coding. You should try to use the same code language between different forms which are developed as it allows for code reuse and a steeper learning curve. C# is the most recent and provides the greatest set of core functionality followed by VB. VBScript and JScript offer less, but are very common and easy to code in terms of syntax strictness.

No need to over do it!
After saying all this, I should stress a few key points:

• If a form is simple code may not be required. If a form doesn't require complex validation, formatting and rules, as well as not having a large number of fields in the main data source it should be quicker to set up using the tools provided InfoPath.
  

• It does take time to learn how to use code to enhance form functionality and reduce development time for complex forms. Don't dive straight in the deep end; break up what you are trying to do, then learn and implement individual components as required. Individual components developent in a separate form can be saved in a separate location easily for use in future form development.
  

• Reuse Code and Form layout. Write code in ways that make it reusable. Create snippets and forms containing individual functions, or a set of related functionality to start building up a "bank" of resources. Reuse a previous form's layout as a starting point for aesthetics when developing a form set, or forms which incorporare company branding.