InfoPath 2010/2013 was a promising platform which allowed non-developers to enable and deploy amazing things. You could create minor applications or major enterprise applications with InfoPath. The back end is XML which was an ultra portable file format. The integration with SharePoint made this a fantastic way to design forms, design workflow, attach binary, and collect digital signatures. With XML you could push this to an organizational record management system or transform the result data however you saw fit. You could push it to a SQL database and leverage XQuery or other techniques to run reporting. However, Form Services never panned out to be user friendly. A SharePoint patch caused your working form to collapse or a workstation patch caused your InfoPath Designer or Client to stop functioning correctly. You developed InfoPath forms with conditional formatting, binding, new schema updates, and versions. You developed various techniques to manage and work with InfoPath but it never felt "programmer friendly". This part of the development strategy is not to show you how to develop for InfoPath but to start the dialog on how to progress away from InfoPath using a real world example. This particular example is a mock-up of an actual application that ran into web server, configuration, and authentication limitations. It began as a promising development experiment but quickly became frustrating to users and developers (i.e., Server limitations, File attachment size limitations, User profile integration, and security based conditional activities.) We will use the succeeding posts to project the form into a full application.
- XSD/XML schema = List Definition
- XSL = Convert list schema to HTML via DataViewWebParts/ListViewWebParts
- Conditional binding and controls = SharePoint web controls and jQuery