Archive for category InfoPath

Different views for display, edit and new item in InfoPath list forms

Custom lists and InfoPath forms make a good combination, although InfoPath in this scenario lacks some functionality but still this combination is hard to avoid in many situations. You can check out my previous post about the differences between InfoPath in form library, InfoPath with custom lists and aspx forms for custom lists.

When working with InfoPath custom list forms it’s sometimes required to have different views for new, edit and display item modes of the form.

Display View

There are two ways you can choose display view otehr than the default view.

First is in “advanced form options” in InfoPath file menu, here you can choose your display view.

 

Advanced form options

Advanced form options

 

 

Second options is outside InfoPath and it applies not only to display mode but also to edit and new modes.

Suppose you want a different view for display item mode.

1. Open the site in SP Designer

2. Open list detail page and open displayifs.aspx in ‘Forms’ list

3. Select the Infopath viewer webpart and look in the properties window, you will find the “DefaultView” property inside “Misc” section

Same can be done in newifs.aspx and editifs.aspx for new and edit item modes

 

New Item View

It’s easy just check empty ID field in InfoPath rule on form load and change view. Or use the above mentioned designer option.

 

Edit Item View

If you have set different display view and switching view for new item on form load based on empty ID field, then for edit item mode just leave it to the default view. And of course you can change in SP designer as mentioned above.

 

Leave a comment

Comparison between Aspx forms, InfoPath list forms and InfoPath documents in SharePoint 2010

When it comes to data entry forms in SharePoint, there are three out of the box options available, Aspx forms (default option in lists), InfoPath List forms, and InfoPath documents. The first two are interchangeable with some effort, but switching from the first two to InfoPath documents and visa versa is not possible. Therefore, it’s important to choose the right approach in the beginning of a project.

Here’s the comparison of these three technologies.

 

ASPX forms

InfoPath List Forms

InfoPath Documents 

Basics

Separate forms for display, edit and new items. Forms simply work on whatever data is in the list.

Single form works for all operations. Like aspx forms, this form works on whatever data is in the list.

Each list/data item is a document itself. Documents can be configured to promote fields to library columns

Form cannot be printed

Form cannot be printed

Form CAN BE printed

Data cannot be saved as draft

Data cannot be saved as draft

Document can be saved as draft

     

Coding Support

Client and server side code support

No client or server side code support

Only server side code support, it uses XMLHttp in order to avoid full page postbacks during data entry.

     

Form Design

CSS can be applied

No CSS support

No CSS support

     

Data

Data can be changed or imported into the list in bulk

Data can be changed or imported into the list in bulk

Only existing data in promoted fields can be modified. Records cannot be added or deleted in bulk.

Multiple data sources are not supported unless they are in the form of lookup columns or used in client or server side code

Multiple data sources can be used

Multiple data sources can be used

Managed Meta data can be mapped to fields

Can NOT use Managed Meta data

Can NOT use Managed Meta data

Can use external data through client or server side code

Can consume simple SOAP and REST based services and can have connections to databases and XML files

Can consume simple SOAP and REST based services and can have connections to databases and XML files

     

Form Functionality

No built in support for cascading drop downs, this functionality is achieved using JavaScript

 

Cascading drop downs can be created without code

Cascading drop downs can be created without code

No repeating or nested data support

No repeating or nested data support

Repeating and nested data support, but cannot be promoted to separate columns or lists

Multiple views of data cannot be created

Multiple view of data CAN BE created and switched based on rules

Multiple view of data CAN BE created and switched based on rules

Multiple web part can be added to the form, inline editing of records possible

Data can be shown from multiple data sources, but can’t be changed

Data can be shown from multiple data sources, but can’t be changed

     
 

Validation

JavaScript for all the rules and client side validation

Rule engine does it all

Rule engine does it all

     

Workflow

SPD based list and reusable workflows and VS based custom workflows can be created and attached

SPD based list and reusable workflows and VS based custom workflows can be created and attached

SPD based list and reusable workflows and VS based custom workflows can be created and attached. Only promoted fields can be used in SPD based workflows.

     
     

Key Benefits

Maximum control on the form

Very easy to develop and very little testing is required

Easy to develop and relatively less testing is required

JavaScript/JQuery and Server side code support

Can be developed with minimum time and effort

Server side code support

CSS Support

InfoPath Views, Rules and facial features are supported

All InfoPath features like Views, Rules, facial features and printing are supported

Data in the list can be edited, imported and exported in bulk

Data in the list can be edited, imported and exported in bulk

Repeating and nesting data support

     

Multiple web parts can be used on a form to view or modify items from different lists on a single form

   
     

Drawbacks

Increased development and testing time

No Coding support

No client side coding support, limited server side code ability

   

Can run in Sandbox

     

 

Deciding the right technology

 InfoPath form library should be the first consideration for all kind of applications. They provide additional functionality compared to custom list InfoPath forms, such as;

  • Repeating tables and complex schema 
  • Printing views 
  • Better deployment and change support
  • Managed code support 
  • Forms can be digitally signed 

 

There are few situations where list based InfoPath forms suite;

  •  System needs to be built upon existing data and it’s not feasible for all that data to be entered through the forms
  • Bulk data import and edit is required throughout the life of the system
  • None of the above mentioned additional capabilities of InfoPath is required 

 

ASPX list forms should be used only when

  •  JavaScript support is a must
  • CSS support is required
  • SharePoint Managed Meta Data must be used in forms

 

 

 

 

3 Comments