• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lotus Forms Webform Server 3.0 Overview & Architecture
 

Lotus Forms Webform Server 3.0 Overview & Architecture

on

  • 1,801 views

This presentation provides a functional and technical overview of Lotus Forms Server - Webform Server 3.0. It includes several architecture diagrams as well as an overview of how Webform Server ...

This presentation provides a functional and technical overview of Lotus Forms Server - Webform Server 3.0. It includes several architecture diagrams as well as an overview of how Webform Server transforms XFDL and XForms forms into HTML and JavaScript forms for display in a browser.

This presentation includes:

* What’s new in 3.0
* 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

Statistics

Views

Total Views
1,801
Views on SlideShare
1,800
Embed Views
1

Actions

Likes
0
Downloads
26
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Lotus Forms Webform Server 3.0 Overview & Architecture Lotus Forms Webform Server 3.0 Overview & Architecture Presentation Transcript

  • Webform Server 3.0 Overview and Architecture
  • Agenda
    • What’s new in 3.0
    • 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
  • What’s New in 3.0
  • What’s new in 3.0?
    • Support for iSeries (under PASE) server side
    • Support for Firefox 2.0 on Mac and Vista for client side
    • Supports JavaScript API
    • Must use SQL database for Access Control Database
      • Allows ACS to be clustered to provide failover mechanism
      • Supported DB: DB2, Cloudscape (Apache Derby)
    • Print to PDF, PDF/A
    • PKI and Authenticated Clickwrap Signing Support
    • Performance Improvements
      • Templating
      • On Demand Page Loading (ODPL)
    • Added BIDI support (Hebrew and Arabic)
  • 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, (New)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.
      • (New in 3.0) Support for 18 Arabic Locales and 1 Hebrew Locale
      • All Webform Server interface elements reflect language selected.
      • Forms remain in the language they were designed – does not translate forms.
  • Where does it work?
    • Server Support
      • Supports WAS V 6.0.2 and 6.1.0 (dropped 5.1)
      • Supports Portal V 6.0.1 (dropped 5.1.0.1 – 6.0.0)
        • (New) 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
    • New to 3.0 is the ability for users to be able to 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.
    • (New in 3.0) 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.0 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 template 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 forms in the template 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
      • Do not allow number of template instances > fcCacheSize
    • 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.
    • (New) 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=&quot;text/javascript&quot; SRC=&quot;LF_XFDL.js&quot;></SCRIPT>
      • <SCRIPT TYPE=&quot;text/javascript&quot; SRC=&quot;LF_FormNodeP.js&quot;></SCRIPT>
    • Files are found in
      • C:Program FilesIBMLotus FormsServer3.0Webform 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:
        • calendar, slider, RTF fields
    • Printing
      • Print version is based on XFDL file, not HTML.
      • PNG 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 new 3.0 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.
    • New to 3.0 is better support for 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 that try to replace the entire data model are ignored.
      • 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)
    • Calendar Widget
      • Converted to date field in Webform Server
    • 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.
    • 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 support 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=&quot;global&quot;> <global sid=&quot;global&quot;> <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.
  • 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: 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
    • Location: form global, page global
  • 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
    • Location: form global, page global
  • 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
    • Location: form global, page global
  • 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
    • Location: form global, page global
  • 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 screenreader)
      • 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?