Monday, February 27, 2012

IPFS in SharePoint 2010

So, in my old work environment, we had a number of rather elaborate code-behind forms hosted in IPFS. My boss there made a wise decision to keep those applications running in MOSS while gradually porting those solutions into SP2010. I was dimly aware of the fact that porting IPFS 2007 forms into SP2010 was effectively a game of roulette, so I was pleasantly surprised when the three forms we currently use at my new company ported with some degree of ease.

Ironically, the form with the most code-behind (for item uploads, sending mail notifications, rolling comments in a repeating section, and a host of other tidbits) had no problems whatsoever. The form that I experienced the biggest number of issues with had almost no code at all, and the code it did have was simply an autonumber generation system.

This form uses a drop-down category selector that, when changed, would show/hide a number of other drop-downs based on the category selected. In the past, each of these categories was located in its own section with duplicate bindings to the same parent group (I'm not a huge XML guy, so I have little doubt that this is highly offensive to someone). So, when you change the category, one section unhides, and the currently visible one disappears. The sub-selections each use a OWSSVR.dll query to filter on a specific list using the category selection as a parameter, so we have a different data source for each category. Simple enough (but not really). I could have managed this in code-behind to a degree, but I'm not a fan of using OnFormXmlChange events in IPFS, and I didn't want the user to have to click a button after selecting a category to re-run the lookups.

Anyway...

Further down this form lie a number of XHTML fields.

For some inexplicable reason, whenever the category selection changes (either in a new form, or changing the selected value in an existing form), one or more of these XHTML fields would suddenly become read-only (and any existing text would be concealed).

Flailing away at the form template like a coffee-dependent monkey eventually gave rise to the realization that in SP2010, upon form redraw (as might happen if a control is being shown or hidden), the fields are actually being reloaded and their contents re-rendered, and it seems as though having to redo this redraw effort with the extra sections caused the redraw to fail prematurely, and so some controls would not completely load.

At first I experimented with cloning the category drop-down into a series of radio selectors. Using these made the problem less prominent, but it would still occur. Finally, I removed the sections and placed each of the six sub-selects into a single section and set the conditional formatting on each control itself, rather than a governing section, and in general this made the behavior go away (though it still manifests when the Category selection changes, the redraw seems to finish when the sub-selection is changed).

I met with the owner of the system employing this form today to show him my work in redesigning the original work to conform to my new IPFS form layout (since I had to touch the form anyway to fix the 2010 issues, I modified its layout to conform to the styling I plan to employ for all my forms here). During our demo, we came across another issue.

Now, cascading drop-downs are nothing new in InfoPath, but the behavior of these in IPFS 2010 is a little different and might cause me some grief down the road. Normally, any data source queries in InfoPath lookups will always have a blank entry at the top of the query. I have a rule set to reinitialize the value in this sub-select if the category changes (since obviously that value is no longer valid). When the category changes, the drop-down does indeed clear, however the previous selection is still shown in the drop-down's values! What exactly is going on here?

Clearly there's a new renderer at work to go along with the SP2010 engine, but I'm puzzled by some of these not-particularly-complex bugs popping up (and unfixed in Service Pack 1). We're currently planning to fast-track our migration into SP15 (possibly even skipping the SP2010 visual upgrade!), so maybe I should just hold my breath for a year.

No comments:

Post a Comment