Last week I presented one of our most popular webinars: Build Better Forms with InfoPath and SharePoint. As part of the registration process, one of the attendees asked about the limitations of InfoPath when compared to ASPX (Active Server Page Extended File) forms. This isn’t a topic I’d addressed in previous webinars, but I added a few slides to discuss it. In this post, I’ll expand on that information and discuss the pros and cons of InfoPath vs ASPX.
InfoPath vs. ASPX: Background
InfoPath forms can be deployed in a variety of ways, but in this post I’ll concentrate on how they work when published to a SharePoint 2010 or SharePoint 2013 site.
InfoPath is a Microsoft Office WYSIWYG application used to create – and sometimes complete and submit – XML (Extensible Markup Language) forms which use DHTML (Dynamic HTML) and XSLT (Extensible Style Sheet Language) for formatting and interactivity.
A form template is created, with an internal data source and form controls that are bound to the data. The template is published to a special Form Library on the SharePoint site. When the form template is published, any or all of the fields in the data source may be promoted to be visible metadata columns in the library. Each time a form is completed and submitted, a new InfoPath document is created which contains the data provided, and any of the promoted fields are metadata for that document.
The form can also submit data to other data sources as well, such as directly to SQL or Access or to other systems via a web service. InfoPath can have “code behind” if the functionality of the form needs to be extended via a language such as JavaScript or C#.
ASPX forms are created in Visual Studio (or, in some cases, SharePoint Designer). They are deployed as simple web pages in a SharePoint site; the entire purpose of the form is to gather data and send it somewhere. This is usually done through a method built into the form, and programming on the server processes the information and sends it on. Of course, developing these forms requires someone with programming know-how, whereas an InfoPath form can be built and deployed by a power user.
There is a common assumption that ASPX forms are, by default, more sophisticated and powerful. That CAN be true, but depending on what functionality is needed, a careful comparison of InfoPath vs ASPX can reveal that an InfoPath form actually can be the better solution. To explain the differences, first it’s helpful to understand a little bit more about the integration between InfoPath and SharePoint.
InfoPath and SharePoint
As mentioned above, the end user can complete and submit a form using the InfoPath client application. They go to the SharePoint library where the template has been published, and click on Add Document or New Document to open a blank copy of the form. The form opens in InfoPath (operating in Filler mode); the user fills in the fields and submits (or saves, depending on how the form has been set up). This, of course, requires that the end user have the InfoPath client application installed on their computer.
For organizations which have SharePoint Enterprise with Forms Services activated, the form designer can choose to have the form open in the web browser rather than in InfoPath filler. This means that the end user needs only a browser to open, complete, and submit the form. The downside to this option is that there is slightly less functionality available in browser forms than what is available with a filler form.
In SharePoint 2010 a new option became available: InfoPath can be used to edit the out-of-the-box list item forms. In previous versions of SharePoint, you had to use SharePoint Designer if you wanted to customize the New, Display, and Edit forms associated with a list. In addition, deployment and functionality of these custom forms often didn’t work well. With SharePoint 2010 with Forms Services, customization of forms is done with InfoPath, and you only have to edit the master rather than separate forms for New, Display, and Edit.
The functionality available for list forms is a subset of what’s available for from-scratch browser forms published to a Form Library.
InfoPath vs ASPX: The Comparison
So, if you compare InfoPath vs ASPX, what is the result? You might think that ASPX forms would give you all the functionality of an InfoPath form, and then some. That’s true … and it’s not. The fact is that InfoPath can do some things that ASPX can’t. So, there’s an area of overlap, but each technology has unique benefits.
Here is a summary of those unique benefits that each provides:
InfoPath | ASPX |
Can receive from / send to multiple data sources | Can make use of Managed Metadata |
Repeating / nested data | JavaScript / JQuery and Server side code support |
Multiple views of data | CSS Support |
“No Code” solutions
|
In summary, InfoPath is a valid, professional-level tool that can be used by power-users and developers alike to create powerful XML forms, whether or not they are published to SharePoint. It falls short when complex, sophisticated coding is needed, but has features that make it more flexible in some ways than ASPX forms. An added benefit is that development and deployment time can be much shorter, and development does not require a .Net programmer. A comparison of InfoPath vs ASPX is not a slam-dunk: The best solution for any given situation could be the “end user” tool InfoPath.
Many of these InfoPath features are demonstrated in my webinar, a video of which is available on our web site: http://sharepointsolutions.com/SharePoint-Training/Pages/Webinars.aspx. We also provide hands-on instruction and practice with these features in our course InfoPath 2010/SharePoint Server 2010 No-Code Workflow Deep Dive. For information on our other classes, visit our full list of SharePoint training courses.