Researching on how to export file attachments from Lotus Notes to InfoPath

Well I have not quite figured this out yet. But I have some pieces to the puzzle. It’s easy for me to get a file attachment in a Lotus Notes document and detach it with code. I can track the file name and the stored location.

Attaching it into an XML file is where the challenge lies. However, I found this Support document on the Miccrosoft Help and Support web site: How to encode and decode a file attachment programmatically by using Visual C# in InfoPath (http://support.microsoft.com/kb/892730).

The problem that I foresee is that I have to include the code with the InfoPath form template and the form template must be fully trusted. These are not good options if I want to use Form Services. Nor will it be easy to convert the file and import it.

I need a way to encode and import the file attachment into the XML itself.

Another option that I have considered is a way to store the file attachments in a separate list and just include a link to the file attachment in the InfoPath form. Of course, this introduces new problems. How do I store the file attachment in a separate list? What is this list and where is it located? What about security requirements?

I’m still thinking this all through. An even bigger challenge is embedded objects in rich text fields in Lotus Notes.

Some other manifest.xsf entries

There are of course many entries in the manifest.xsf file. Some are required and others are optional. Some should be added when using InfoPath with the InfoPath client. Others should be avoided or disabled when using Form Services.

I always enabled the importParameters tag and set some default values for the documentVersionUpgrade tag.

<xsf: importParameters enabled=”yes”></xsf: importParameters>

<xsf:documentVersionUpgrade>
  <xsf:useTransform transform=”” minVersionToUpgrade=”0.0.0.0″></xsf:useTransform>
</xsf:documentVersionUpgrade>

In the beginning, I found the <xsf: views default=”Issue”> tag to be a bit more complex. This is not referring to a Lotus Notes-like view. Instead, it refers to the different forms that can be used to display the stored content. For example, there could be different forms for reading and editing. I add the following tag so that the view can be opened in design mode. Note that the designMode attribute is specified as normal. Normal is the same as not specifying a value.

<xsf: view name=”Issue” caption=”Issue” designMode=”normal”>

Next, the main stylesheet must be defined for viewing content. Issue.xsl is defined below.

<xsf: mainpane transform=”Issue.xsl”></xsf: mainpane>

Then an <xsf: editing> section is included to define how the rich text fields should appear when editing. I have already defined which fields (Details, RelatedDocuments) are of a rich text type elsewhere. Now I need to define the editing component (rich) and the associated properties (autoComplete=”no” and component=”xField”) for these two fields.

<xsf: editing>
<xsf: xmlToEdit name=”RichText_0″ item=”/RecordCollection/Details”><xsf:editWith type=”rich” autoComplete=”no” component=”xField”></xsf: editWith></xsf: xmlToEdit><xsf: xmlToEdit name=”Details_10″ item=”/my:myFields/my: Details”><xsf: editWith type=”rich” autoComplete=”no” component=”xField”></xsf: editWith></xsf: xmlToEdit>
<xsf: xmlToEdit name=”RichText_4″ item=”/RecordCollection/RelatedDocuments”><xsf:editWith type=”rich” autoComplete=”no” component=”xField”></xsf:editWith></xsf: xmlToEdit><xsf: xmlToEdit name=”RelatedDocuments_14″ item=”/my:myFields/my:RelatedDocuments”><xsf:editWith type=”rich” autoComplete=”no” component=”xField”></xsf: editWith></xsf: xmlToEdit>
</xsf: editing>

Unbound controls are defined in the <xsf:unboundControls> section. For example, I can define action buttons here.

<xsf:unboundControls>
<xsf:button name=”CTRL_BTN_Details”>
</xsf:unboundControls>

Next, I can define additional application parameters. The lastOpenView parameter identifies the name of the view that was last open in Microsoft Office InfoPath 2007 design mode.  The scriptLanguage parameter identifies the name of the scripting language used to implement the business logic of the Microsoft Office InfoPath 2007 form. The allowCustomization parameter identifies whether the Microsoft Office InfoPath 2007 form can be modified or customized.

<xsf: applicationParameters application=”InfoPath Design Mode”>
  <xsf: solutionProperties lastOpenView=”Issue.xsl” fullyEditableNamespace=”http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-01-01” lastVersionNeedingTransform=”1.0.0.2″ scriptLanguage=”JScript” allowCustomization=”yes” automaticallyCreateNodes=”yes”></xsf: solutionProperties>
 </xsf: applicationParameters>

There are some more settings that I’ll try to cover in my next blog entry. Then I’ll circle back to other XML files.