Chapter 2. Features and functionality 21
Figure 2-2 shows the Workplace Forms Viewer interface.
Figure 2-2 Workplace Forms Viewer Interface
2.5 Workplace Forms Server
In this section we describe the various features of the Workplace Forms Server.
2.5.1 Workplace Forms Server API
The IBM Workplace Forms Server - Application Programmer Interface (API) is a collection of
specialized functions that you can use to develop applications that interact with XFDL forms.
The API provides a C and Java interface for Windows® and UNIX® computers, as well as a
COM interface for Windows platforms.
The API is divided into two sections, reflecting two sets of functionality:
The Form Library:
The Form Library is a collection of functions that enables you to access and manipulate
XFDL forms as structured data types. These functions provide your applications with a
means of reading and writing forms, retrieving information contained in graphical form
elements, and assigning information to these items. Once the API loads the form into
memory, you can use Java methods (or C functions) to populate the form, retrieve data,
duplicate and destroy form elements, extract enclosures, and even verify digital
Form Toolbar (optional)
22 IBM Workplace Forms: Guide to Building and Integrating a Sample Workplace Forms Application
The FCI Library:
The FCI library is a collection of specialized functions that enables you to develop your
own functions. XFDL forms can then access these custom functions, thereby extending
the capabilities of the Internet Commerce System, without requiring an upgrade to either
your forms software or to the form description language (XFDL). This allows you to provide
custom form functions that you can call from within the form. This is similar to calling
system form functions such as set or toggle.
Typical API uses
The Workplace Forms API is used in a variety of ways and in several places. On the client
side of things, developers may create extensions to the Workplace Forms Viewer, using the
API, that allow form manipulation — that is, modifications to the form (usually in response to
user input) as the user completes it. These extensions are referred to as IFXs. An IFX can
also be used with the client-side Viewer to integrate with other hardware, typically hardware
that collects information that must eventually end up in a form, such as scanners, bar code
readers, or GPS (Global Positioning Systems).
On the server side, the API may be used within a Java servlet or similar piece of code that is
designed as an interface between Web-based forms and a database. This database
interaction permits automatic retrieval of data to prepopulate form items, and seamless
submission of form data (or the entire form) to the database. Workflow integration can be
accomplished in much the same way.
Occasionally it may be necessary to integrate with additional libraries. On either the client
side or the server side, using the API will allow you to use function libraries not provided with
Workplace Forms API, such as voice input libraries.
Any application that has its own application programmer interface in either Java, COM, or C
can be integrated with the Workplace Forms API. Most modern databases also support XML
natively so storage and retrieval of form or XML model data can be quick and seamless and
extensive field to database coding can be minimized.
Additionally, because the Workplace Forms form is a complete document, forms can be
stored directly in the database and retrieved as a whole document.
On the server the API is commonly used with servlets, Java Server Pages (JSP™), and
Common Gateway Interfaces (CGI).
Custom client side functionality is generally supported through custom IFX extensions (code
extensions) provided in either Java, C, or both. Java extensions that do not require any
system access may be embedded directly in a form.
Workplace Forms API versus XML Parsers
Some developers may prefer to use a third party XML parser to interface with their forms.
Depending on the parser and the types of tasks to be performed, this may provide some
benefits in terms of speed or developer comfort (if the developer has a great deal of
experience with XML parsers).
However, the API is able to perform some tasks that are impossible for an XML parser. For
example, computes can continue to run in the form (or be activated by the API) while the form
is in memory, so any form data that is dependent on continuously evaluated computes will
remain accurate. Additionally, since most applications use compressed forms, which cut down