Freigeben über

SharePoint Development - Part 1 (InfoPath)

  • Artikel

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.

(source post and documentation)

The intent of this form was to collect metadata with attachments (i.e., MS Word, MS PowerPoint, and/or other files.)  The aggregate of this metadata and the files were submitted for approval via workflow.

Sample Form

The sample InfoPath form

 

InfoPath is based completely on a XML with a well defined schema. The IDE is easy to use and allows you to rapidly create fields and mappings.

The XSD markup drives the strict XML output

 

The output of the form is raw XML with various namespaces that InfoPath and SharePoint use to render and process the XML.

Note the core XML structure appears as the XSD has defined it.

 

InfoPath leverages Extensible Stylesheet Language (XSL) to transform the XML into a view.  XSL is the backbone of many SharePoint Add-Ins and continues to be the core backbone for rendering components of SharePoint into HTML.  We will navigate through each sample to identify similiar capabilities with development:

  1. XSD/XML schema = List Definition
  2. XSL = Convert list schema to HTML via DataViewWebParts/ListViewWebParts
  3. Conditional binding and controls = SharePoint web controls and jQuery

The XSL transforms the XML into a specific view in the InfoPath form

 

Previous: SharePoint Development Overview | Next Step: Out of the Box