Search This Blog

Tuesday, March 22, 2011

InfoPath Forms vs ASP.NET ASPX Forms

InfoPath Forms

Let’s begin by taking a look at InfoPath.  InfoPath is a great tool for creating simple data-entry forms, and for retrieving data from a variety of data sources.  In addition, it’s great when you need to submit data to a SharePoint form library for the purposes of leveraging a SharePoint workflow.  Where InfoPath breaks down is when we need to submit data to other sources, or when we need to provide a rich user-interface with robust controls and data validation.  Let’s take a look at some pros and cons of InfoPath:


  • Great for submitting data to SharePoint or a SharePoint workflow
    Most of the time when we’re using electronic forms, it is to support a workflow process.  As you [should] know, a SharePoint workflow runs for a specific list item, and data needed for the workflow needs to be entered into the fields for that particular list item in order for the workflow to see it.  Because of this fact that the data actually needs to be a list item, InfoPath is a great choice, because you can effortless promote form fields as columns in your list, which the workflow can then use.
  • Great for retrieving data
    InfoPath provides a very simple wizard interface for selecting a data source for data retrieval.  You can easily select a web service, and XML document, or a SharePoint list and have that data appear in your form pretty easily.  You can also connect to a SQL database and retrieve data from tables, views, or stored procedures.
  • Great for simple end-user form development
    InfoPath is great for creating a simple form with a few fields and simple rules and simple data validation.  I keep emphasizing simple because once you introduce complex business rules, data validation, conditional formatting, or complex data presentation that pushes the limitations of InfoPath, you will be forced to get very creative which often involves some sort of custom coding.
  • Most of the time only requires SharePoint site permissions
    Unless you are creating a browser-enabled form with .NET code-behind, or your form requires Full Trust and uses the InfoPath client, it’s relatively easy to deploy a form to SharePoint.  Simply publish the form to the desired form library and you’re good to go.  However, as soon as you introduce .NET code in a browser-enabled form, you need to install and activate the form to Central Administration and activate the newly-created feature at the site collection level.  You will need to have access to Central Administration and to the site collection in order to activate these features.


  • Difficult to submit data to non-SharePoint data sources
    Like I mentioned, InfoPath is great for submitting data to a SharePoint form library.  It is not so great for submitting the data to anything else.  If your form is submitting data to a single (single being the operative word here), then you could potentially configure the form to submit directly to a table.  However if the data needs scrubbed or manipulated, chances are you will need to submit the data via a stored procedure, which InfoPath cannot do.  For this, you will be forced to develop a custom web service that accepts the data either field-by-field, or as a giant blob of XML that you have to parse through, which you then have to submit to the database by writing traditional ADO.NET code.  Not too simple anymore, huh?
  • Limited user-interface
    InfoPath allows you to create forms with a variety of standard controls, such as textboxes, date pickers, radio buttons, checkboxes, buttons, drop-down lists, repeating tables, etc..  Unfortunately, it is pretty much limited to those items (you get a few more with the rich client, but that’s beyond the scope of this post).  You don’t have any type of tree view control, no multi-select list box, no tab control, no image buttons, and no grid view control. The lack of a grid view control is a deal breaker in many cases, because we often have to present long lists of data, and the built-in repeating table doesn’t support sorting, grouping, or paging.  Yuck.  Finally, there’s no way to add HTML or CSS to your form, meaning that it can’t inherit any SharePoint styles, and you’re limited to what you can design in the form.  This frequently gives an inconsistent look and feel for a SharePoint process.  Again, yuck.
  • Difficult to secure sensitive data
    Assuming the InfoPath form is being submitted to a SharePoint form library, any data the form contains is inherently insecure.  The form is just saved to the form library like any other document, except as an XML document.  This means if your form contains social security numbers, salary information, or any other type of sensitive data, a user could download the XML file and open it in Notepad.  Even if the data isn’t visible through InfoPath, the data is still stored in the form and can be viewed by any user that knows how to download.
  • Difficult to integrate with Forms-Based Authentication
    Although browser-enabled forms will work with forms-based authentication, the useful username() function no longer works.  This means that even if you’re logged into your SharePoint site as a valid FBA user, InfoPath will have no idea who you are.
  • Not developer-friendly
    If you’ve made it this far in this post, you’ll have already read that while simple things are easy to accomplish in InfoPath, complicated things aren’t and often requires .NET code.  While you can definitely add .NET code to a form, it’s not the same type of form coding a typical developer is used to.  You have to parse XML to retrieve field values, you have to parse XML to set field values, and you’re still pretty much limited to the functionality that you have through the designer.  You can just write more complex business rules and logic, you can’t make the form or the field controls behave any differently.
  • Licensing
    Obviously your users need to be licensed for InfoPath Forms Services before they’re able to use it. Even if you have licenses for the InfoPath client, separate licenses are required for browser forms. If the users are internal and members of your domain, you must be licensed for InfoPath Forms Services, which is available either through the MOSS Enterprise CAL or the standalone InfoPath Forms Services CAL.  If the forms are going to be available externally to non-domain users or anonymous users, then you must be licensed for either Office Forms Services for Internet Sites or be licensed for SharePoint for Internet Sites, which is the external connector that provides the ability for an unlimited number of users to access and use InfoPath through a browser.

Creating ASP.NET ASPX forms offer the most in terms of flexibility, as you can do anything that you can do in a traditional ASP.NET web site, including HTML, CSS, JavaScript, and even AJAX.  A lesser-known technique is integrating these pages into the SharePoint “shell” to give users a seamless experience.  It doesn’t take much effort to have SharePoint host these pages and have the master page and styles applied to your custom forms.  Let’s take a look at some pros and cons associated with ASP.NET forms:


  • Great for submitting data to non-SharePoint data sources
    While InfoPath is great at submitting data to a SharePoint form library, ASP.NET forms are great for submitting data to everything else.  You can easily write your ADO.NET code or whatever-you-like code to submit to your data source, and not have to worry about parsing a bunch of InfoPath XML first in order to pull out the values.  It’s a lot less work to get the data into your data source.
  • Great for providing a rich user interface
    Unlike InfoPath, you aren’t limited to a tiny set of field controls.  You can use whatever an ASP.NET web site supports, including tree view, tab controls, grid views, AJAX – even Silverlight if you really really want.  You can also provide any type of business rules and validation you like as well, including summaries, friendly pop ups, etc.  Also, since the pages are inheriting the SharePoint styles and master page, your forms will automatically pick these styles up, and will also use the master page.  This gives the appearance that they’re actually built-in SharePoint pages.  It’s slick. There are plenty more options for developing a rich and clean user interface if you’re developing ASP.NET forms.
  • Developer friendly
    This one’s a no-brainer.  Obviously if you’re familiar with ASP.NET and .NET programming, creating data-entry forms are a cinch.  There’s no learning curve with learning how to code an InfoPath form, and you don’t have to learn the ins and outs of the InfoPath object model.  This opens up the development work to a wider audience of our developers, as not many have hands-on experience with writing .NET code behind an InfoPath form.  In addition, should any future updates be required to the form or the code, finding resources on ASP.NET online or hiring someone with ASP.NET skills will not be a difficult task.  It’s a widely practiced technology, and there are a ton of resources.
  • Can provide secure means of sensitive data access
    Since no data is actually stored in the ASP.NET form, it provides a much more secure way of viewing sensitive data, as it will have to be retrieved and submitted to the database directly.  A user can’t download an ASP.NET form and see the data like they can with an InfoPath form.
  • Integrates well with Forms-Based Authentication
    By using an ASP.NET form in an FBA-enabled site, we are able to see the user that is currently logged in, unlike with an InfoPath form.
  • Access to the SharePoint Object Model
    Since the ASP.NET forms are running under the context of the SharePoint site they’re accessed from, we can use the SharePoint Object Model to do whatever we wanted.  We could very easily access SharePoint list or site data, user profile information, etc., and bind that information to controls on the form.  To do this in InfoPath, you’d have to use the unfriendly out-of-the-box SharePoint web services, or write your own.
  • Licensing
    Not required! There aren’t any licensing headaches when exposing ASP.NET forms to users, even externally.  Obviously since they’re going to be integrated into SharePoint, you’ll have to have the appropriate licenses for that, but nothing specific to the forms themselves.


  • Potential additional development overhead
    Obviously writing custom ASP.NET forms requires a competent ASP.NET developer, which may not always be available (though I’d argue that in order to develop some of the complex forms that we have had to do in the past – you will still need a very competent .NET developer).  In addition, changes to simple business rules or data validation is more difficult to accomplish in ASP.NET than in an InfoPath form.  If the form is simple and doesn’t require data going to SQL, then an end-user is probably better of just using InfoPath.
  • Requires file system access on SharePoint server
    To deploy custom ASP.NET forms to SharePoint, they need to be placed onto each web front-end’s file system.  In addition, the assembly must be deployed to the GAC or to the web site root’s BIN directory.  Either way, the developer must have access to the file system, or to someone that has access to the file system.
  • Not business-user friendly
    One good thing about InfoPath is that business users can even build simple forms.  They will probably not be able to develop an ASP.NET form in .NET.  If the form is truly that simple, then creating ASP.NET forms is probably overkill anyways, and InfoPath should be the recommended solution.


So, How Do I Choose?
Great question! The answer should be easy -- do the simplest thing possible that will result in a clean solution.  If you can implement the desired functionality quickly and painlessly in an InfoPath form, then by all means do that.  If developing an InfoPath will actually be prohibitive to functionality and future maintainability, then consider building custom ASP.NET forms.

No comments:

Post a Comment