Professional InfoPath 2003 [Electronic resources] نسخه متنی

File→Merge Forms and select one or more forms (the source) to add to the one that is already open (the target).

When new story meta data arrives from NewsLine contributors, editors will merge or import the new material into their existing forms. Of course, it would be possible for them to use the standard interface provided in InfoPath. However, to meet the NewsLine requirement, you’ll also need to update the status value and two dates on all the imported stories.

One way to do this is to use XSLT in a custom merge. Merging can include some or all of the data in the source and target forms. In this case you’ll do a simple copy of existing data in the source. Then you’ll change the status value to “In Review” and set the receptionTime and the modificationTime.

Making a Custom Transform

The default merging operation works well for forms that are based on the same XML schema. But it is also possible to override the default merge operation, or even merge forms based on different schemas.

To do this, you can create an XSLT script that contains aggregation instructions for the merge. The transform is applied at merge time to create an XML DOM document containing the information to be imported, together with annotations specifying how to incorporate this information into the target document. These annotations are XML attributes with values that serve as aggregation instructions specifying how each node should be merged with the target form.

Because we are merging forms from a single schema, we don’t need to follow this approach in much detail. So we’ll just briefly note the purpose of these attributes in the agg namespace [http://schemas.microsoft.com/office/InfoPath/2003/aggregation.]

A full explanation of the use of the attributes and their values with examples are available in the InfoPath Developer SDK.

Creating the XSLT

From Chapter 4 you’ll recall the XSF declarations for importing in the importParameters element. You’ll need to make appropriate entries here. The name attribute of the xsf:importSource element contains the form template’s name. Usually, you can leave this empty. The schema attribute contains the name of a schema file. The transform attribute contains the name of the transform that you’ll use for merging.

<xsf:importParameters enabled="yes">
   <xsf:importSource name=" schema="meta1.2.xsd" transform="merge.xsl"/>
</xsf:importParameters>

There must also be references in the files section of the form definition file to any custom transform files. Here we show the references to merge.xsl and the included file, date.msxsl.xsl, that handles the date/ time value production:

<xsf:file name="merge.xsl">
   <xsf:fileProperties>
      <xsf:property name="fileType" type="string" value="resource"/>
   </xsf:fileProperties>
</xsf:file>
<xsf:file name="date.msxsl.xsl">
   <xsf:fileProperties>
      <xsf:property name="fileType" type="string" value="resource"/>
   </xsf:fileProperties>
</xsf:file>

When designing your transform, decide whether you want to use merging from XML location paths or merging from InfoPath aggregation instructions. You can start with a simple identity transform that copies all the source data across.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:agg="http://schemas.microsoft.com/office/infopath/2003/aggregation"
xmlns:target="http://schemas.microsoft.com/office/infopath/2003/aggregation-target"
xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2003-05-29T20:30:47">
  <xsl:template match="/">
      <xsl:copy>
      <xsl:apply-templates select="@* | node()" />
      </xsl:copy>
  </xsl:template>
  <xsl:template match="@* | node()">
      <xsl:copy>
      <xsl:apply-templates select="@* | node()" />
      </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

Now you can override the basic transform with templates for the elements that need updating. The status element is straightforward:

<xsl:template match="status">
   <status>In Review</status>
</xsl:template>

Date/time values are a little more complex. Because there are no date-related functions in XSLT 1.0, you’ll need to use one of the useful EXSLT recommended extensions to obtain a system value.

We’ve used the EXSLT dateTime extension developed by Chris Bayes. It employs a function to be used with the Microsoft XSLT engine. To include it, you’ll need to make the following additions to the namespace declarations and specify the func:script element. The function date:dateTime always returns a UTC date with the appropriate time zone value.

Then you can call the new function to return a value, and make the updates.

xmlns:date="http://exslt.org/dates-and-times"
xmlns:func="http://exslt.org/functions"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
extension-element-prefixes="date msxsl">
   <func:script
   language="exslt:msxsl"
   implements-prefix="date"
   src="date.msxsl.xsl"/>
   
   <xsl:include href="date.msxsl.xsl"/>
   <xsl:variable name="datetime"
   select="concat(substring(date:dateTime(),1,19),’Z’)"/>
   .
   .
   <xsl:template match="receptionTime">
      < receptionTime >
         <xsl:value-of select="$datetime"/>
      </ receptionTime >
   </xsl:template>
   <xsl:template match="modificationTime">
      <modificationTime>
         <xsl:value-of select="$datetime"/>
      </modificationTime>
   </xsl:template>
   .
.