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

component attribute of an editWith element. You’ll probably recall that editWith defines the behavior of an editing control and specifies the use of the component. It also provides the parameters to determine the component behavior.

As a reminder, Figure 8-1 shows the content model.

Figure 8-1: The editWith content model.

Here’s a recap on the attributes of editWith that you first met in Chapter 3:

caption is an optional identifier for alternate forms of XML data used in the component.

component is the name of the editing component, referenced by the action attribute of a button element.

autoComplete switches the auto-completion of controls on or off.

proofing does the same with proofing features, such as the spelling checker.

removeAncestors specifies the number of ancestor elements to be removed when the last item is removed.

field specifies a relative XPath expression from the item attribute element.

type specifies the type of editing for the fields that match the XPath expression specified by the item attribute of xmlToEdit.

xField

The xField component allows users to edit XML nodes as text or rich text boxes. There are five possible values for the type attribute, but only data that is in a CDATA section, or that corresponds to XHTML, can support values other than plain:

plain (default)—Wrapped or unwrapped text

plainMultiline—Paragraphs with no formatting

formatted—Formatting with no paragraphs

formattedMultiline—Formatting and paragraphs

rich—Tables, images, and other objects

Plain text is what you’ll use most of the time, and it could hardly be more straightforward. For more elaborate formatting, you need a rich text control, and that raises an interesting schema design point.

Suppose you want your users to be able to add features like paragraphs, tables, and emphasis to a meta data description element, with an XSF structure like this.

<xsf:editing>
   <xsf:xmlToEdit name="description_1" item="/meta/description">
      <xsf:editWith type="rich" autoComplete="no" component="xField"/>
   </xsf:xmlToEdit>
</xsf:editing>

You might think that you can just point to the data source and define the field as rich text. Unfortunately, you can’t, and the requirements for this component may make it difficult for you to import existing XHTML data to rich text.

If you want to bind an element to a rich text field, you must use the following type of declaration in the form schema. The element name defined in the name attribute can be anything you like.

<xsd:element name="richText">
   <xsd:complexType mixed="true">
      <xsd:sequence>
         <xsd:any namespace="http://www.w3.org/1999/xhtml"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>

Of course, this structure only gives you just one named element. If you have more than one rich text area, it is better to create a complex type and refer to it, along the following lines. Figure 8-2 illustrates the structure.

Figure 8-2: The content model for the xText component using rich text.

<xsd:element name="description" type="richText"/>
   .
   .
<xsd:complexType name="richText" mixed="true">
   <xsd:sequence>
      <xsd:any namespace="http://www.w3.org/1999/xhtml"
processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
</xsd:complexType>

InfoPath inserts an XHTML fragment in the element content. Note the namespace declaration in the XHTML elements:

xmlns="http://www.w3.org/1999/xhtml"

Microsoft seems to have decided to use div tags to contain text blocks, rather than paragraph elements, as the following example shows:

<description>
   <div xmlns="http://www.w3.org/1999/xhtml">
      <font size="2">
      <div>
         <strong>
         <font face="Trebuchet MS" color="#969696" size="5">SOAP Version 1.2</font>
         </strong>
      </div>
      <div> </div>
      <div>
         <font size="2">
         <font size="2">
            <div>Simple Object Access Protocol (SOAP) is a lightweight
protocol intended for exchanging structured information in a
decentralized, distributed environment.</div>
            <div> </div>
         </font>
         </font>
      </div>
      <div>
         <em>
         <font color="#008080">
            <strong>Part 1 Messaging Framework</strong>
         </font>
         </em>
         <font size="2">defines the SOAP envelope, an overall framework
for representing the contents of a SOAP message, identifying who should deal
with all or part of it, and whether handling such parts are optional or
mandatory. It also defines a protocol binding framework, which describes
how the specification for a binding of SOAP onto another underlying protocol
may be written.</font>
      </div>
      <div> </div>
      <div>The example shows part of a SOAP envelope header.</div>
      <div> </div>
      <div>
         <font face="Lucida Console">&lt;env:Header&gt;<br/>  &lt;m:reservation</font>
      </div>
      <div>
         <font face="Lucida Console">  
     xmlns:m="http://travelcompany.example.org/reservation" <br/>  
    env:role="http://www.w3.org/2003/05/soap-envelope/role/next"<br/>
      env:mustUnderstand="true"&gt;<br/>  
 &lt;m:reference&gt;</font>
      </div>
      <div>
         <font face="Lucida Console">      uuid:093a2da1-q345-739r-ba5d-</font>
         <font face="Lucida Console">pqff98fe8j7d</font>
      </div>
      <div>
         <font face="Lucida Console">&lt;/m:reference&gt;<br/>
&lt;m:dateAndTime&gt;2001-11-29T13:35:00.000-05:00&lt;/m:dateAndTime&gt;<br/>
&lt;/m:reservation&gt;<br/>
&lt;n:passenger xmlns:n="http://mycompany.example.com/employees"<br/>
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"<br/>
env:mustUnderstand="true"&gt;<br/>
&lt;n:name&gt;Mike Smith&lt;/n:name&gt;<br/>
&lt;/n:passenger&gt;<br/>&lt;/env:Header&gt;<br/>
         </font>
      </div>
      </font>
      <div>
      <font size="2">
         <div>
         <font color="#008080">
            <em>
            <strong>Part 2 Adjuncts</strong>
            </em>
         </font>
         <font size="2">defines a data model for SOAP, a particular encoding
scheme for data types which may be used for conveying remote procedure calls
(RPC), as well as one concrete realization of the underlying protocol binding
framework defined in Part 1. This binding allows the exchange of SOAP messages
either as payload of a HTTP POST request and response, or as a SOAP message in
the response to a HTTP GET.</font>
         </div>
         <div> </div>
         <div>
         <strong>Acknowledgement</strong>
         </div>
         <div>This description is adapted from the W3C SOAP tutorial,
 which you can access at:
<a >
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/</a>
         </div>
      </font>
      </div>
   </div>
</description>

However, whatever you may think of the quality of the XHTML code generation, you have to admit that using rich text shows off the InfoPath UI. Figure 8-3 illustrates a little of what is possible, including multiple fonts, highlighting, formatting for style and different colors, and a hyperlink. Notice the spelling checker at work in the code example. (And if you read it carefully, you can learn a bit about SOAP, including where to find a tutorial.)

Figure 8-3: A rich text control.

xTextList

The xTextList component corresponds to bulleted, numbered, or plain lists. The component consists of one or more identical elements that are siblings under the node described in the item attribute on the containing xmlToEdit element. The schema for an xTextList element is shown in the following example. Figure 8-4 illustrates the model.

Figure 8-4: The content model for the xTextList component.

<xsd:element name="subjects">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element ref="subject" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
<xsd:element name="subject" type="subjectType"/>

The XML data looks like this:

<subjects>
   <subject>George Bush</subject>
   <subject>World Bank</subject>
   <subject>Matsushita</subject>
</subjects>

User actions to split, merge, and remove items are associated with the Enter, and Backspace, or Delete keys, respectively. All three actions require that the insertion point be within a field in the list.

split creates a copy of the current item XML node and inserts it as a sibling after the current one. It fills the field nodes with the content preceding and following the insertion point. Because the split is associated with the Enter key, the fields may not be any of the multiline field types. Only the types plain and formatted are supported.

merge additionally requires that the insertion point be at the beginning of a field node, and there must be another field node before it. If the insertion point is at the beginning of the field, merge deletes the current content and appends it to the content of the preceding field.

remove removes the current node.

xCollection

The xCollection component allows the insertion and removal of repeating sections or tables. This requires two levels of nesting: a group within a group and the second group containing the table or other field elements. The schema shows the structure, and the content model diagram is shown in Figure 8-5.

Figure 8-5: The xCollection content model.

<xsd:element name="resourceList">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element ref="meta" minOccurs="1" maxOccurs="unbounded"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
   <xsd:element name="meta">
      <xsd:complexType>
            <xsd:sequence>
               <xsd:element ref="creator" minOccurs="1"/>
               <xsd:element ref="title" minOccurs="1"/>
               <xsd:element ref="date" minOccurs="1"/>
               .
               .
            </xsd:sequence>
   </xsd:complexType>
</xsd:element>
<xsd:element name="creator" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="date" type="xsd:date"/>

The form instance data will look like this:

<resourceList>
   <meta>
      <creator>Ian Williams, Pierre Greborio</creator>
      <title>Professional InfoPath 2003</title>
      <date>2004</date>
   </meta>
   <meta>
      <creator>Michael Kay</creator>
      <title>XSLT Programmer’s Reference, 2nd Edition</title>
      <date>2001</date>
   </meta>    
    </resourceList>

All the following actions require the current context to be within the scope of a container.

With the insert action, if the insertion point is within an item, the insertion is equivalent to insertAfter. Otherwise, InfoPath inserts the fragmentToInsert at the end of the content of the appropriate parent node, and/or add attributes to the parent node. If the current context has a mapping to within some other child node of the parent node, the insert will be after that node, rather than appended to the content. A button entry for this action is in the msoInsertMenu and msoStructural EditingContextMenu named menu areas.

insertBefore and insertAfter require that the current context be within a node. These actions insert the fragmentToInsert before or after the current node, and/or add attributes to the parent node. Button entries for these actions are in the msoStructuralEditingContextMenu named menu area.

remove requires that the current context be within a node. The action removes the node. If the removeAncestors attribute is not zero, this action also removes the corresponding number of parents/ancestors of the item XML node. Button entries for this action are in the msoStructural EditingContextMenu named menu area (for the context menu and the shortcut menu).

removeAll requires that the minOccurs value for the element in the schema be 0. The action removes all XML nodes that are descendants of the container node and satisfy the item XPath pattern. If the removeAncestors attribute is not zero, it also removes the corresponding number of parents/ancestors of the item XML node.

xOptional

xOptional applies where the inserted data is an optional item. Only one instance of the optional data can be inserted.

<xsd:element name="meta">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element ref="releaseTime" minOccurs="1" maxOccurs="1"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>

All insert and remove actions require the current context to be within the scope of a container.

insert requires that the container node does not already have a descendant satisfying the item XPath. It appends the fragmentToInsert at the end of the content of the appropriate parent node, and/or adds attributes to the parent node.

remove requires that the current context be within an item. The action removes the item. If the remove Ancestors attribute is not zero, this action also removes the corresponding number of parents/ ancestors of the node.

xReplace

xReplace provides a replace action, allowing different versions of content specified in the schema xsd:choice element to be replaced by one another.

replace is enabled when the current context is an item. The action replaces the current item by the xmlFragment.

<xsd:element name="rights">
   <xsd:complexType>
      <xsd:choice>
         <xsd:element ref="rightsAgent"/>
         <xsd:element ref="copyright"/>
      </xsd:choice>
   </xsd:complexType>
</xsd:element>

Again, this requires two levels of nesting, with two or more section controls within a group. Figure 8-6 illustrates part of a typical structure.

Figure 8-6: The xReplace content model.

In the following example from a form definition file, the rightsAgent element replaces copyright. There is, of course, a comparable entry for the rightsAgent element.

<xsf:xmlToEdit name="rightsAgent_13" item="/resourceList/meta/rights/copyright"
container="/resourceList/meta/rights">
   <xsf:editWith caption="Rights Agent" xd:autogeneration="template" component="xReplace">
      <xsf;fragmentToInsert>
         <xsf:chooseFragment>
            <xsf:rightsAgent/>
         </xsf:chooseFragment>
      </xsf:fragmentToInsert>
   </xsf:editWith>
</xsf:xmlToEdit>

xReplace is intended for simple pairings like this, although in principle, there can be more choices. However, the permutations could become unmanageable as the options increase.

xImage

xImage corresponds to an image control and specifies the XML item in which the image data is inserted or referenced.

As a quick reminder, the relevant xImage declaration in the form definition file will look something like this:

<xsf:editing>
   <xsf:xmlToEdit name="embedded" item="person/thumbnail">
      <xsf:editWith component="xImage"/>
   </xsf:xmlToEdit>
<xsf:editing>

Form users can insert images in fields you have specified as an xImage component or in rich text fields. For example, you might want users to be able to add a photograph to a personnel record (or possibly a thumbnail that opens a larger linked file). Figure 8-7 shows the user interface for an image field.

Figure 8-7: An image filed in the user interface.

Image Fields

In design mode you can define picture elements as embedded or linked objects. As with other forms of linking and embedding, you have to weigh several options.

On the one hand, embedding an image adds to the size of the form, and any XML processor outside of the InfoPath environment will have to know how to handle the binary data in the element content. On the other hand, with linked information, there are issues regarding ongoing access to the images that users can link to.

In your main form schema, the respective element declarations should have the following data types. Embedded images must be encoded as xsd:base64Binary data, and linked image elements as xsd:anyURI.

<xsd:element name="thumbnail" type="xsd:base64Binary" nillable="true"/>

<xsd:element name="linked_image" type="xsd:anyURI"/>

Images in Rich Text

When a user inserts an image in a rich text field, InfoPath includes it as an inline XHTML img element. The embedded binary value of the image is base64 encoded as an attribute of the element.

<div>
   <img
   style="WIDTH: 52px; HEIGHT: 29px" tabIndex="-1" height="29"
   src="msoinline/a3baabfb94ed43b8"
   width="52"
   xd:inline="iVBORw0KGgoAAAANSUhEUgAAADQAAAAdBAMAAAAX9VImAAAAMFBMVEUAAADAwMD///
8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACVom0/AAAACXBIWXMAAA7EAAAOx
AGVKw4bAAAAB3RJTUUH0wkBES4SCIhwFgAAAAd0RVh0QXV0aG9yAKmuzEgAAAAMdEVYdERlc2NyaXB0
aW9uABMJISMAAAAKdEVYdENvcHlyaWdodACsD8w6AAAADnRFWHRDcmVhdGlvbiB0aW1lADX3DwkAAAAJ
dEVYdFNvZnR3YXJlAF1w/zoAAAALdEVYdERpc2NsYWltZXIAt8C0jwAAAAh0RVh0V2FybmluZwDAG+aH
AAAAB3RFWHRTb3VyY2UA9f+D6wAAAAh0RVh0Q29tbWVudAD2zJa/AAAABnRFWHRUaXRsZQCo7tInAAAA
lUlEQVR4AbWRURKEIAxDWW7AnqD2/oc0iRYorF87dkbH+hoSa/HHKo/EX0Jlqhru8rI5S2+E+qBGoiNK
otESZVHvgRYRXigUP3lHdLR/UamG45VIDjiQhrpHVTfDM66I8UP1WkKmuosprm1sO/y0xiGud9mUtYEW
GURdtfxlkIHSNij6hpf7wcmpFJUxUJlIFCjLrvET5edWL/Z50k4AAAAASUVORK5CYII="
   xmlns:xd="http://schemas.microsoft.com/office/infopath/2003"/>
</div>

Persistent Images

By persistent images we mean those that appear on every form instance. You might want to include something on every form for a group of users, such as a company logo or an icon associated with the type of form or even the view in use. Persistent images can also be structured as hyperlinks.

You can insert this type of image in design mode by choosing Insert→Picture. If you embed the image, InfoPath renames the image file and adds it to the files section of the XSF file. InfoPath then adds an HTML img element to the style sheet for the form for both linked and embedded images, with the linked or renamed file in the src attribute.

Supported Image Formats

Your users can insert several graphics file formats into forms, either directly or with the use of graphics filters.

File Types That Do Not Require Filters

You don’t need a separate graphics filter installed to insert the following file formats:

Enhanced Metafile (.emf)

Graphics Interchange Format (.gif)

Joint Photographic Experts Group (.jpg)

Portable Network Graphics (.png)

Microsoft Windows Bitmap (.bmp, .rle, .dib)

Windows Metafile Graphics (.wmf)

Tagged Image File Format (.tiff)

Encapsulated PostScript (.eps)

File Types That Require Filters

You will need a graphics filter installed to insert all other graphics file formats. These graphics filters are not supplied with the standalone version of InfoPath. To use the filters, you need to install the appropriate Microsoft Office edition or a standalone version of Microsoft. The following list contains common file types and the corresponding graphic filters that are supported. For additional documentation on these formats, see InfoPath Help.

Computer Graphics Metafile (.cgm)

CorelDRAW (.cdr, .cdt, .cmx, and .pat)

FlashPix (.fpx)

Encapsulated PostScript (.eps)

Hanako (.jsh, .jah, and .jbh)

Kodak Photo CD (.pcd)

Macintosh PICT (.pct)

PC Paintbrush (.pcx)

WordPerfect Graphics (.wpg)

Additional Filters

For information on graphics filters that you can download, choose Help→Office on Microsoft.com to connect to the Microsoft Office Web site.