Webform Server 351 Architecture and Overview

Webform Server 3.5.1 Overview and Architecture

Agenda
What’s new in 3.5.1
About Webform Server
Architecture Overview
Scaling Webform Server
Creating a Servlet
Creating a Portlet
Differences Between Webform Server and Viewer
Form-based Settings
Document Accessibility Wizard

Prerequisites
Students should have a basic understanding of the Lotus Forms (previously Workplace Forms) suite of software, including:
What XFDL is
How the Viewer works
Students should also have a basic understanding of servlet/portlet architectures

What’s New in 3.5.1

What’s new in 3.5.1? (1 of 2)
New Installer
Single installer allows for installation of any or all products: Webform Server, API, Forms Services Platform, Turbo.
Support for zLinux
XFDL 7.7 Language
IBM Mashup Center widget
Webform Server ships with a Mashup widget that allows you to connect any Lotus Forms form to other widgets in a mashup.
WebSphere Application Server 7.0
Support has been added for WebSphere Application Server 7.0
XHTML output
You can configure Webform Server to produce valid XHTML 1.0 Strict output. See the Configuring a servlet and Configuring a portlet topics for more information.
Print Output Format
Forms printed via Webform Server can now have their print output format controlled at the form or application level, instead of depending on the configuration of the Webform Server translator applying its output format setting to the form.

What’s new in 3.5.1? (2 of 2)
Support for modifiable ufv_setting
Previously this option was only supported in Viewer. This will make the form readonly.
GZIP compressed JavaScript
To decrease page loading time, Webform Server now sends compressed JavaScript to Web browsers that accept gzip content encoding.
Font caching
Modifications to the font caching mechanism can improve overall server performance and reduces memory usage.
Improved PNG encoder
This improves performance of printing and rendering of forms with images.
Resolved APARs
Technote lists all resolved APARs -> http://

About Webform Server

What is Webform Server?
A Zero Footprint Forms Solution
Lotus Forms are rendered directly in a web browser as DHTML.
Uses same XFDL files as Viewer.
XFDL forms are converted to DHTML, then sent to user.
DHTML is converted back to XFDL when user submits form.
Forms looks almost exactly as they do in the Viewer.
Most notable difference is the toolbar Webform Server provides, although this toolbar can be removed if desired.
Removes the need to deploy and manage the Viewer.
Forms are accessible to all users, including general public.

What is Webform Server
A Cross-Platform Fill Experience
Supports both Windows and Macintosh.
IE 6.0, Windows 2000 sp4, Windows XP sp1, sp2
IE 7.0 for Windows XP sp2, Vista
Firefox 1.5, and 2.0 Windows and Macintosh
Provides a cross-platform front-end for forms applications.
Can be used as forms front-end for applications, just like Viewer.
An Internationalized product
Supports G0, G1, and G2, and some G3 languages.
Support for 18 Arabic Locales and 1 Hebrew Locale
All Webform Server interface elements reflect language selected.
Form remain in the language they were designed – does not translate forms.

Where does it work?
Server Support
Supports WAS V 6.0.2, 6.1.0 and 7.0
Supports Portal V 6.0.1 (dropped 5.1.0.1 – 6.0.0)
Multiple forms may appear on a portal page at same time
Platform Support
Server is supported on:
AIX 5.2, 5.3 (pSeries 32bit) w/ XL C/C++ Final 7 Runtime PTF or later
Solaris 9 – 10 (SPARC 32bit)
Linux RH ES/AS 4.0 (Intel 32bit)
SUSE Linux Enterprise 10 (32-bit intel)
MS Windows 2000 Server SP4 and 2003 Server Standard Ed. (Intel)
iSeries (PASE) 5.3, 5.4

How does it work?
Works as either a servlet or a portlet (JSR 168)
You code a servlet/portlet that extends the Webform Server framework.
Servlet/portlet processes the XFDL form.
Translation of form to HTML is ‘invisible’ to the servlet/portlet application.
Automatically detects Viewer
If the end-user has the Viewer installed, it will serve XFDL – if not, HTML.
You can force HTML if you prefer.
Provides accessibility support
Provides support for enhanced focus indicator (as in Viewer) and JAWS screen reader - V7.10.

How does it look?
Almost exactly like Viewer, except:
Some differences in form appearance due to nature of HTML widgets.
Only 6 buttons on toolbar.
Intended to replicate look and feel of Viewer
Maintains “sign what you see” philosophy.
Forms signed in Webform Server will look the same when inspected in Viewer, and vice versa.

How does it look?

How does it look?
Open Form – opens form from local file system.
Save Form – saves form to local file system.
Print Form – prints form to local printer.
Refresh Form – refreshes data model and redraws form.
Toggle Accessibility Mode – enables enhanced focus indicator and screen readers.
Enter Wizard Mode – displays fields one page at a time (accessibility)
About – provides version information for Webform Server.

What is Webform Server Not?
Webform Server is not a zero-cost Viewer replacement.
Does not provide all of the functionality of the Viewer.
Differences are discussed in detail later.
Imposes a heavier load on the server.
Forms must be translated before they can be served to the user.
Increased traffic between server and client.
Requires development of a servlet/portlet application.

Architecture Overview

How does Webform Server work? Logging Service Shared File Space C L I E N T Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator

How does Webform Server work (Request HTML)? Logging Service Shared File Space GET request HTML response C L I E N T Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator

How does Webform Server work (Request Form)? Logging Service Shared File Space XFDL response GET request DHTML DHTML C L I E N T Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator

How does Webform Server work (Submit Form)? Logging Service Shared File Space XFDL response Post DHTML DHTML XFDL request DHTML C L I E N T DHTML Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator

How does Webform Server work (AJAX Updates)? Logging Service Shared File Space C L I E N T Ajax User Event Ajax Client Forwarder Ajax User Event Change list returned (Ajax) User Event Forwarder ‘ Running’ Form notified of event Change list retrieved and sorted XML change list created Change list (Ajax) Changes made to HTML Form Cache (Memory) Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Translator

How does Webform Server work (XForms Submit)? C L I E N T Ajax User Event Ajax Client Forwarder Ajax User Event Change list returned (Ajax) User Event Forwarder ‘ Running’ Form notified of event Form Updated with New Data XML change list created Change list (Ajax) Changes made to HTML Web Service Or XML over HTTP Request Response Do XForms Submit Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Translator

Scaling Webform Server

Webform Server Scalability
Vertical Scaling
You can deploy multiple Translators to the same machine, and the machine will be able to respond to the same level of requests, but with better response times.
Horizontal Scaling
You can deploy many Translator machines as a cluster behind a load balancer
Supports WAS ND (Network Deployment)
You can deploy many App Server machines as a cluster – and they each can point to a single load balancer as their Translator – session affinity must be enabled so that the same translator responds to every request for a given form.
Many Translators can share the same Log Server
Log Server can be replicated – but rarely required.
Translators should share the same Access Control DB
Access Control DB can be replicated, but single access point is required (virtual IP).
Translators should share the same Shared File Cache
Normally a networked file share
Each Translator (or multi-translator machine) can have its own Shared File Cache

Webform Server Architecture Browser Optional Cluster Server Optional Cluster Server Logging Service Shared File Space How does it scale? Access Control DB Access Control DB Portal/Application Server Webform Server Translator Portal/Application Server Webform Server Translator Portal/Application Server Portlet/Servlet Wrapper XFDL Forms Portlet/Servlet PE API Portal/Application Server Portlet/Servlet Wrapper XFDL Forms Portlet/Servlet PE API Portal/Application Server Portlet/Servlet Wrapper XFDL Forms Portlet/Servlet PE API Portal/Application Server Webform Server Translator

Signature Support
Users can sign using their Generic RSA or CryptoAPI based certificates, or Authenticated Clickwrap.
An ActiveX control is automatically installed the first time a user requests to sign. ActiveX control provides certificate selection and signing functionality.
Once installed, user can select certificate (from IE Store only) and form will be signed – but no overlap and layout tests are done (Viewer only).
ActiveX control performs signing client side – certificate is not transported.

Print to PDF
Default is still to print to PNG.
Must change translator.properties file to enable printing to PDF or PDF/A
Can set printOutputFormat to one of:
png — Outputs a PNG file (default).
pdf — Outputs a PDF file.
pdfa — Outputs a PDF archive file.
gif — Outputs a GIF file.

Creating a Servlet

Creating a Servlet
Extend IBMWorkplaceFormsServerServlet class
Provided as part of Webform Server framework.
Extends the HttpServlet that is normally used for servlets.
Write your servlet as normal
Your servlet will work with an XFDL file, it will never see HTML.
Your servlet can call the Workplace Forms API, or any other APIs.
Servlet can serve both HTML and XFDL
By default, Webform Server will auto-detect Viewer and serve the right file type.
Functions useHTML and useXFDL allow you to set a specific response type.

Creating a Servlet
Set up your web.xml file to include Webform Server configuration
Detailed in Administration Guide.
Package your servlet as a war file
Package your application along with some key supporting files (jars).
Package can also contain the forms you want to serve to users.
Deploy your servlet to your application server

Templating
Normally, a web application uses our API to load a blank form, pre-populate it, and then the form is sent to the Translator, who it turn loads the form in the API again. Very expensive.
Most web applications serve the same form(s), but might pre-populate the with user data before serving the form out to the user.
You can tell the Translator what forms your application is going to be serving out. These forms are called Templates.
The Translator will then build a cache of instances for each Template, and as instances of that form are used up, the Translator will replenish its cache automatically.
Even when template cache is exhausted under load, resources (images, etc) are shared between template instances, so memory utilization is more efficient.
Additional classes and methods have been added to the framework to handle Templates: TemplateManager.

Templating Interface
Call getTemplateManager() to get a TemplateManager Object.
TemplateManager has the following method:
addFormTemplate() - add a form as a Template to the Translator
There are more methods, but don’t use them just yet.
To use an instance of a template, call
this.setTemplateId(response, template id)
This informs the translator that you want to send an instance of that template to the user.
Prepopulation
this.addXFormsInstance() will add the passed XForms instance data into the template instance before it is passed to the user
See JavaDocs in infoCenter for further details

Template Example
public class MyServlet extends IBMWorkplaceFormsServerServlet
public void init()
{
FileInputStream fis = new FileInputStream(aTemplateFile);
this .getTemplateManager().addFormTemplate(“TemplateID_123”, fis);
}
public void doGet()
{
this .setFilename(response, someFileName);
this .setFormName(response, “someFormName");
response.setContentType("application/vnd.xfdl");
this .setTemplateId(response, “TemplateID_123”);
// could also call this.addXFormsInstance() to pre-populate form
}

Samples Show Templates in Action
Both Servlet and Portlet Sample Code have been updated in 3.5.1 to show how to use Templates
New FormTemplates Directory has been added.
Any forms placed into SampleForms/FormTemplates directory will be pushed as a Template to the Translator.
Compare the response time between a form loaded as a template, and the old fashioned way.
The larger the form, the more effective Templating is.

translator.properties and Templates
translator.properties file has poolSize property that controls the number of instances (per Template) the form cache is supposed to have available. (default setting is 1)
If you have 5 template forms, and poolSize = 4, then the translator will attempt to keep 5 * 4 = 20 templates in the form cache.
fcCacheSize – The maximum number of forms a translator will keep in memory at any given time – default 30
The number of template instances counts towards this number
In memory concurrent users = fcCacheSize – number of template instances
If form cache is maxed, and it needs more room, translator will evict either user forms or templates from cache as follows
If template instances > user forms – it will evict a template instance
If user forms > template instances – it will evict a user form
This ratio will be configurable in a later release.

Exercise: Altering Sample Servlet
In this exercise, we will load the sample servlet provided into Eclipse, understand what it does, modify it, and deploy the resulting application to WAS.
The modification will consist of adding a hidden datestamp field to the form, then reading that field with the servlet and storing the submitted form in a folder based on the datestamp.
This will give you a quick look at the basic process of creating a servlet-based Webform Server application.

Examining the Sample Servlets
3 servlets: FormViewServlet, FormListServlet, SampleUtilities

FormListServlet
FormListServlet provides a list of forms (one form in this example) in an HTML page for the user to select, with options for forcing Viewer, forcing HTML, or auto-detect Viewer.
Parameters passed to FormViewServlet determine this: mode=xfdl, mode=HTML. Leaving out mode parameter results in auto-detect.

FormViewServlet
FormViewServlet extends IBMWorkplaceFormsServerServlet. This is where the “work” happens.
doGet method sends form to user
doPost method accepts form as submission and writes the form out to a directory
handleReplaceAll method accepts a xformsreplaceall action from the form and returns the text of the xforms:submit in a new browser window
New sample code to show how Templating is done.
loadFormTemplates method shows an example of how to tell the Translator what forms your application is going to use as Templates

Creating a Portlet

Creating a Portlet
Extend IBMWorkplaceFormsServerPortlet class
Provided as part of Webform Server framework.
Extends the GenericPortlet that is normally used for portlets.
You implement a doViewEx method and a processActionEx method, which extend the normal doView and processAction methods.
Write your portlet as normal
Your portlet will work with an XFDL file, it will never see HTML.
Your portlet can call the Workplace Forms API, or any other APIs.
Many Forms can be displayed on a single portal page

Creating a Portlet
Portlet can serve both HTML and XFDL
By default, Webform Server will auto-detect Viewer and serve the right file type.
Functions useHTML and useXFDL allow you to set a specific response type.
Set up your portal.xml to include Webform Server configuration
Detailed in Administration Guide.
Package your portlet as a war file
Package your application along with some key supporting files (jars).
Package can also contain the forms you want to serve to users.

Creating a Portlet
Deploy your portlet to your application server
All steps are documented in more detail in the Webform Server Administration Guide. Examples shipped with product are a good starting point.

Communicating Between Portlets
Portlets often need to communicate with each other
One portlet may present a list of all forms, and a second may display the form the user selects.
First portlet must tell the second which form has been selected.
Session beans are one approach
User selects a form, which triggers processActionEx of first portlet.
Portlet writes details about which form was selected to a session bean.
Once the portlet’s action is finished, all portlets update.
As part of update, second portlet runs doViewEx, which reads the information from the session bean.
Second portlet then loads and displays the correct form.
Other approaches are also possible
JavaScript API

JavaScript API
Both Viewer and Webform Server support the the JavaScript API.
JavaScript normally exists in main html or jsp page, where forms or other html pages exist within frames or div tags.
You must include the LF_XFDL.js and LF_FormNodeP.js in your web application, and then load them in any html page that wishes to use the JavaScript API as follows:
<SCRIPT TYPE="text/javascript" SRC="LF_XFDL.js"></SCRIPT>
<SCRIPT TYPE="text/javascript" SRC="LF_FormNodeP.js"></SCRIPT>
Files are found in
C:Program FilesIBMLotus FormsServer3.5Webform Server edist

JavaScript API Example / Exercise
To setup the example, you must have a running Webform Server with the Sample Servlet running.
Place the LF_XFDL.js and LF_FormNodeP.js files in the root of the Servlet Sample war file:
C:WAS DIRinstalledAppsprofileWebformSampleApp.earSamples.war
Place the js_example.html and top_frame.html file in the same directory
Navigate to the js_example.html file through the servlet sample
http://localhost:8085/Samples/js_example.html
In the lower frame, open the preapprovalForm.xfdl file in the Webform Server
You should then be able to click the buttons in the upper frame, and see how the JavaScript API can interact with a live running form under the Webform Server.

Differences Between Viewer and Webform Server

About the Differences
Webform Server generally replicates Viewer functionality.
But, Webform Server cannot do everything the Viewer does.
These differences are caused by a number of factors, including:
HTML has certain limitations that are difficult to overcome.
JavaScript cannot be used to replicate all functionality.
Webform Server requires the user to have a constant connection to network.

Opening and Saving Forms
Forms are typically opened from a web site and submitted back to that site, however…
User can open XFDL forms from local computer
Assumes you provide proper link or leave “open” button active on toolbar.
XFDL form is uploaded to server and converted to DHTML for user.
User can save forms on local computer
Assumes you leave the “save” button active on toolbar.
XFDL version of form is downloaded to user and saved locally.
Allows for “ad hoc” routing of forms.

Form Layout and Printing
Form Layout
Looks almost exactly like Viewer.
Some slight differences due to nature of HTML widgets.
Some widgets not supported:
slider, RTF fields
Printing
Print version is based on XFDL file, not HTML.
PNG or PDF image of form is generated by server and sent to end-user for printing.
Browser imposes it’s own margins on the page, so printable area might be slightly smaller than Viewer.
Form is scaled to account for this.
Best to use PDF printing to better avoid these issues.

Type Checking and Attachments
Type checking is passive, not predictive
The user’s data is not checked until they move the focus to another item
If the data does not match the formatting, it is flagged as an error
Attachments
User can only attach one file to the form at a time
May dictate different form design that used in Viewer

Actions and Computes
Actions are very limited
Actions will not repeat properly
Actions that are set to run once will run every time the page is refreshed
Computes are supported through Ajax, but have some limitations
Some event model computes (activated in popup/combo, keypress, mouseover, printing) are not supported.
Other event model computes (focused, focuseditem) can be turned on or off through the Translator’s configuration file.
Most computes happen real-time without a refresh, but some automatically trigger a refresh.
dirtyFlag **

Submissions and Email
Submissions do not support multiple URLs
Submission will only send data to one URL, regardless of the version of your form.
Submissions and computed URLs
For servlets, computed URLs are supported, but only if they submit to the server that is running Webform Server
For portlets, computed URLs are not supported
Email is not directly supported
No email toolbar button.
Submit buttons with an email URL will not work.
Users must save the form locally, then attach the form to a standard email.

Signatures and Accessibility
Only Clickwrap, Authenicated Clickwrap, CryptoAPI, and Generic RSA signatures are supported
Can create and inspect Clickwrap signatures no matter what browser.
IE required to support Authenticated Clickwrap and CryptoAPI based signatures.
Accessibility similar to Viewer
Supports JAWS screen reader (as opposed to MSAA compliant).
Supports enhanced focus indicator and keyboard shortcuts.
Does not support high contrast mode.
Supports additional W3C accessibility mode (discussed later)

XML Data Model and XForms
XML Data Model is supported, with some exceptions/differences
Can configure whether data model is updated automatically, or only when user clicks update button.
Smartfill feature is not supported.
Web Services are not supported in XML Data Model (but are in XForms).
XForms is supported, with some exceptions/differences
XForms submissions will cause a redraw of the form (unlike Viewer).

Other Differences
XFDL support
Webform Server supports XFDL 6.0 and later (Viewer is 5.0 and later)
Inactive Cells
Webform Server omits inactive cells in IE, but shows them in Firefox
Viewer shows inactive cells in both browsers
Rich Text Fields
Converted to plain text fields in Webform Server

Other Differences
Schema Validation
Restricted to server-side validation in Webform Server
Slider Item
Not supported.
Smartfill
Not supported.
Can create similar effect with XForms submission.
Spellchecking
Not supported.

Other Differences
Viewer Functions (viewer package)
Not supported.
Includes functions such as messageBox, setCursor, and so on.
Viewer Settings (ufv_settings option)
Supports menu, with some differences from Viewer (discussed later).
Supports all of the format error settings (print, save, sign, and submit).
Ignores all other settings, but ufv_modifialble.
List Item
If text in cells is wider than list, text is truncated (Viewer provides scrollbars).

Other Differences
Web Services
Only supported under XForms.
Use XForms submit to send/receive Web Services data.
Viewer Extensions (.ifx files)
Supported on server-side only.
Zoom
Not supported.
Requirements option
Not supported.

Other Differences
“ file” URIs
Not supported for XFDL submission or XForms submissions

Form-based Settings

About Form-based Settings
Individual forms can control Webform Server in the following ways:
Can control which buttons are on the toolbar.
Can control whether forms can be printed, saved, signed, or submitted when they contain formatting errors.
These settings are specific to a single form
The form itself controls Webform Server.
The next form in the sequence can make different settings if desired.
Can include as many settings as needed

About Form-based Settings
Settings are placed within the ufv_settings option
... <globalpage sid="global"> <global sid="global"> <ufv_settings> setting 1 setting 2 ... </ufv_settings> </global> </globalpage> ... Each setting is a child of the ufv_settings option ufv_settings is a child of the global item in the global page (or the global item of any page)

Inheritance
Pages inherit ufv_settings from the form global
ufv_settings on individual pages override any form global settings
Note that ufv_settings acts as a single option for inheritance – either all settings are inherited or no settings are inherited
This means that a single setting on a page will override all settings in the form global

ufv_settings: menu
Sets which buttons are available in the Webform Server toolbar
Can control all buttons except About button, or hide toolbar altogether
Does not affect controls added to the form itself, such as save and print buttons
Three valid settings for each button:
on – the button works normally
off – the button is visible, but inactive
hidden – the button is hidden, and all other buttons shift left in the toolbar

ufv_settings: menu
Default
All buttons are on.
Location: form global, page global

ufv_settings: menu
Each button is represented by its own keyword
Open Form – open
Save Form – save
Print Form – print
Refresh Form – refresh
Toggle Accessibility Mode – accessibility
Entire toolbar - toolbelt
Cannot control the About button.
Preserves product branding.
But can hide toolbar completely.

ufv_settings: menu
<ufv_settings>
<menu>
<save>off</save>
<print>off</print>
<accessibility>hidden</accessibility>
</menu>
</ufv_settings>
<ufv_settings>
<menu>
<visisble>hidden</visible>
</menu>
</ufv_settings>
Turns the save and print buttons off, and hides the accessibility button completely Hides toolbar completely

ufv_settings: modifiable
Default
on.
Location: form global

ufv_settings: modifiable
<ufv_settings>
<modifiable>on</modifiable>
</ufv_settings>
<ufv_settings>
<modifiable>off</modifiable>
</ufv_settings>
Allows the user to edit this form The user can not edit this form. It is read only

ufv_settings: printwithformaterrors
Controls whether the user can print when there are type checking errors in the form
Three settings
permit – the user can print despite type checking errors
warn – the user is warned that there are errors, and is asked if they want to print anyway
deny – the user is informed that there are errors, and is not allowed to print
Default: warn

ufv_settings: printwithformaterrors
<ufv_settings>
<printwithformaterrors>permit</printwithformaterrors>
</ufv_settings>
Allows the user to print when there are type checking errors; does not warn the user

ufv_settings: savewithformaterrors
Controls whether the user can save when there are type checking errors in the form
Three settings
permit – the user can save despite type checking errors
warn – the user is warned that there are errors, and is asked if they want to save anyway
deny – the user is informed that there are errors, and is not allowed to save
Default: warn

ufv_settings: savewithformaterrors
<ufv_settings>
<savewithformaterrors>permit</savewithformaterrors>
</ufv_settings>
Allows the user to save when there are type checking errors; does not warn the user

ufv_settings: signwithformaterrors
Controls whether the user can sign when there are type checking errors in the form
Three settings
permit – the user can sign despite type checking errors
warn – the user is warned that there are errors, and is asked if they want to sign anyway
deny – the user is informed that there are errors, and is not allowed to sign
Default: warn

ufv_settings: signwithformaterrors
<ufv_settings>
<signwithformaterrors>permit</signwithformaterrors>
</ufv_settings>
Allows the user to sign when there are type checking errors; does not warn the user

ufv_settings: submitwithformaterrors
Controls whether the user can submit when there are type checking errors in the form
Three settings
permit – the user can submit despite type checking errors
warn – the user is warned that there are errors, and is asked if they want to submit anyway
deny – the user is informed that there are errors, and is not allowed to submit
Default: warn

ufv_settings: submitwithformaterrors
<ufv_settings>
<submitwithformaterrors>permit</submitwithformaterrors>
</ufv_settings>
Allows the user to submit when there are type checking errors; does not warn the user

Document Accessibility Wizard

About the Wizard
Based on W3C Web Content Accessibility Guidelines v1.0
Accessibility guidelines for page layout in HTML
W3C Recommendation as of May 5, 1999
A new mode in Webform Server
“Wizard” view that only shows one form item at a time
User steps from item to item, going forward or backward
Prints error messages on page, rather than using “fly over” text (easier to read with screen reader)
Uses no JavaScript (part of W3C specification)

Normal Mode vs. Wizard Mode
Normal mode displays whole form
Type checking is automatically performed through JavaScript
Wizard mode displays one item at a time
Type checking performed when user moves to next item (which submits current data)
No reliance on JavaScript
Toggled by Wizard button on toolbar

Labels for Items
Labels are constructed by combining the following elements (in order):
Item’s acclabel option
Item’s help option (text from associated help item)
Item’s label option
You must design the form to account for this – requires accessibility messages to be added to form

Error Messages
Formatting errors are found when the user tries to move to the next item
If an error is found, the item is redrawn with the error text above the label
Errors are constructed from the following messages (in order):
Signature lock error
Format error
Format message
Users cannot move to the next item until the error is resolved

Questions?

http://www-10.lotus.com	312
http://www.slideshare.net	13

Webform Server 351 Architecture and Overview

by ddrschiw on Sep 18, 2009

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 325

Statistics

Webform Server 351 Architecture and Overview Presentation Transcript