Implementing XSL predicates or filters on InfoPath Forms Server 2010
If you downloaded the beta version of InfoPath Forms Service as part of SharePoint 2010 then you will get the chance to try out filtering data in browser forms.
Filtering is supported on the following controls:
Repeating tables, Repeating sections , List Box, Bulleted List, Drop-Down List Box and Numbered List.
If your familiar with InfoPath 2007, then filters are applied to controls in the same way. You can review the following document for how you apply a filter: http://office.microsoft.com/en-us/infopath/HP011066141033.aspx
What I want to discuss in this article is how the filters were implemented on the server.
- Deploying the form.
- When a form is deployed to InfoPath server the .XSN file which contains among other things the .XSL file. The .XSL file is where you will find the XSL predicates or filters. Unlike rules or calculations which are stored in the .XSF file and are InfoPath specific. The predicates found in the .XSL file are predicates which comply with standard XSL predicates in the form of:
Where x/y/z is an Xpath and [expression] is an XSL predicate.
During deployment the XSL is parsed and each expression is evaluated for several criteria. One of the criteria that is evaluated is complexity of the expression. This means several things such as does the expression contain constant values or does it have references to nodes in the main DOM or an auxiliary DOM. Based on the complexity of the expression the nodes involved in the expression may be marked to post back to the server when a value is changed.
After the expressions are evaluated the deployment process continues and a binary form of the InfoPath Form data is written to the SharePoint database.
- Rendering of the form
- When the form is rendered in the browser all of the filter expression will be evaluated on the server before the form is displayed. For instance if a List Box is contains the names of all of the United States and the filter expression is something like this:
[stateField = field1]
Then the List Box filter expression will be evaluated and the data that satisfies the expression will be sent to the browser.
For repeating sections and tables the rendering process behaves slightly different. The expression will still be evaluated however rows that do not satisfy the condition will be marked to not render in the browser. This means that if your repeating table contains 50 rows but only 1 row meets the filter criteria then all 50 rows will be sent to the browser but only one row will be visible in the browser.
This is done because in InfoPath the data in repeating sections and repeating tables may be used in a calculation such as a summation. So in this case it is necessary to hide rows that don't satisfy the expression.
- Runtime of the Form
- When the form is up and running and the user is entering data each field in the browser is mapped to a node in the XML. If one of the nodes in the XML is part of a filter expression then filter will be evaluated when the node is changed. At this point one of two things will happen. One, if the filter is marked to post back the form will send data to the server and the filter will be evaluated on the server and the rendering process will take place again. Two, if the filter is not marked to post back then the filter will be evaluated in the browser and no post back will occur.