Don Reamey's InfoPath Weblog

Implementing XSL predicates or filters on InfoPath Forms Server 2010

dreamey — Fri, 22 Jan 2010 06:44:00 GMT

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:

x/y/z[expression]

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.

Also during the deployment process JavaScript expressions are generated. In the case where an node is not marked to post back to the server the JavaScript expression would be used in the browser. Another form of complexity is when a JavaScript version of the expression can't be generated. This can occur when there are nodes that are "out of context" of the expression. When I say out of context I mean that the expression could reference nodes that are in an auxiliary DOM or nodes that are not a sibling of the nodes in the XPath expression.

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.

InfoPath Server Form Invocation - part 1

dreamey — Mon, 04 Aug 2008 21:20:00 GMT

There are always questions on how does my form know where to open, in the browser or in the rich client?

The simple answer is to set the document library settings to open in the preferred environment. This can be either the InfoPath rich client or the browser.

The problems start to arise when you want to copy and paste a link and put it in email or IM to someone. The issue is how document libraries interact with the list items.

A when you click on an item in a document library there is SharePoint Java Script that gets activated and the script determines some things about your environment. These things are the default item open setting, permissions, type of document etc.

Depending on what the default open item is set to SharePoint may try to invoke InfoPath client or it may try to send the request to InfoPath Forms Service.

Once the decision is made to send the request to InfoPath forms service the URL should look something like this:

http://server/_layouts/FormServer.aspx?XsnLocation=http://server/documentlibrary/Forms/template.xsn&SaveLocation=http://server/documentlibrary&DefaultItemOpen=1

The important things to look at is the DefaultItemOpen. This URL parameter detemines how the server will try to render the form.

DefaultItemOpen = 0 means try to render in the rich client

DefaultItemOpen = 1 means try to render in the browser.

There are other URL parameters such as OpenIn, SaveLocation, XsnLocation, XmlLocation. I will go into more detail about these later. I will also discuss how permissions are handled for forms.

The power of the press

dreamey — Tue, 15 Jan 2008 05:18:00 GMT

I just got the Jan 7th issue of Information Week and i was reading the letters to the editor. There were a couple of letters about Windows Vista in this issue. One of the letters I found very interesting. It stated how arrogant Microsoft was about creating an operating system that is in compatible with the previous version.

The example the writer gave was "Vista isn't compatible with the lower Windows operating systems. For example, if a file is saved in Vista, it can't be opened in Windows; the file can't even be renamed."

Wow! I couldn't believe this letter was published. If you read the quote the writer doesn't say what program they are using they just say if you save a file using Vista. What does that mean? Do they mean a Microsoft Word file? Hmm, I don't know.

The problem is that someone is going to read this letter and take it as a factual piece of information.

Monitoring InfoPath Server

dreamey — Sat, 10 Nov 2007 22:14:00 GMT

Now that InfoPath Server has been out for a while I wanted to get an idea of how people are using it and what type of health monitoring scenarios. The main scenarios we are looking at are around how admins can determine when InfoPath is doing something bad on the server. Such as, a user has deployed a form and it makes a large amount of data connections on start up. Each connection brings back large amounts of data. If this form is used by hundreds of users it could easily bring the overall performance of a server down.

What other types of scenarios would be important to SharePoint administrators?

Dynamic languages vs. static languages.

dreamey — Wed, 24 Jan 2007 06:00:00 GMT

I recently stated doing some work with JavaScript as part of working on infoPath Forms Server. I realized that you can do some pretty powerful and cool things with JavaScript however the lack of strong types is a little hard to get used to.

In Java script you can do things like:

function TestFunction()

{

var myVariable = 33;

alert(i);

myVariable = CallBack;

myVariable();

}

function CallBack()

{

alert("CallBack");

}

In this example I create a variable named myVariable and assign the integer value 33 to it. Then I assign the value or location of the function CallBack to the variable myVariable.

I then invoke the function by treating it as a function i.e. myVariable().

This is pretty cool and very powerful. However, the problem comes when you start looking at a large complex code base. Since there are no types you can’t easily determine the type of a variable. What the InfoPath team has done is used a naming convention for the variables. This allows us to track the object back to a source file.

However, since this is still a non typed language and there is no easy way to use the right click style go to definition found in Visual Studio and other tools.

When learning a new code base tools like this make things much easier. Working in JavaScript is analogous to walking around a dark room looking for a marble.

If anyone has any hints or tips on navigating large JavaScript code base let me know your thoughts.