Webform Server 351 Architecture and Overview
- 1. Webform Server 3.5.1 Overview and Architecture
- 2. 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
- 3. 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
- 4. What’s New in 3.5.1
- 5. 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.
- 6. 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://
- 8. 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.
- 9. 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.
- 10. 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
- 11. 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.
- 12. 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.
- 13. How does it look?
- 14. 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.
- 15. 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.
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. 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
- 24. 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
- 25. 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
- 26. 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.
- 27. 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.
- 29. 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.
- 30. 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
- 31. 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.
- 32. 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
- 33. 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 }
- 34. 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.
- 35. 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.
- 36. 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.
- 37. Examining the Sample Servlets 3 servlets: FormViewServlet, FormListServlet, SampleUtilities
- 38. 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.
- 39. 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
- 41. 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
- 42. 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.
- 43. 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.
- 44. 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
- 45. 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 Files\IBM\Lotus Forms\Server\3.5\Webform Server\redist
- 46. 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 DIR\installedApps\profile\WebformSampleApp.ear\Samples.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.
- 47. Differences Between Viewer and Webform Server
- 48. 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.
- 49. 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.
- 50. 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.
- 51. 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
- 52. 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 **
- 53. 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.
- 54. 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)
- 55. 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).
- 56. 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
- 57. 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.
- 58. 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).
- 59. 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.
- 60. Other Differences “ file” URIs Not supported for XFDL submission or XForms submissions
- 62. 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
- 63. 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)
- 64. 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
- 65. 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
- 66. ufv_settings: menu Default All buttons are on. Location: form global, page global
- 67. 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.
- 68. 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
- 69. ufv_settings: modifiable Default on. Location: form global
- 70. 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
- 71. 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
- 72. 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
- 73. 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
- 74. 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
- 75. 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
- 76. 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
- 77. 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
- 78. 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
- 80. 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)
- 81. 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
- 82. 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
- 83. 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
- 84. Questions?
Editor's Notes
- #9: Webform Server’s toolbar only includes 6 buttons: open, save, print, refresh, accessibility mode, and about. (These are discussed later.) Webform Server removes the need for the Viewer by providing a central site that can serve HTML versions of XFDL forms to users. While there are some minimum browser requirements (discussed later), this can include the general public or any computer-based audience.
- #10: Group 0 = (1 language, 12 locales) English (12 locales) en Australia = en-AU Belgium = en-BE Canada = en-CA Hong Kong = en-HK India = en-IN Ireland = en-IE New Zealand = en-NZ Philippines = en-PH Singapore = en-SG South Africa = en-ZA United Kingdom = en-GB United States = en-US Group 1 = (9 languages, 38 locales) French (5 locales) fr Belgium = fr-BE Canada = fr-CA France = fr-FR Luxemburg = fr-LU Switzerland = fr-CH German (4 locales) de Austria = de-AT Germany = de-DE Luxemburg = de-LU Switzerland = de-CH Italian (2 locales) it Italy = it-IT Switzerland = it-CH Portuguese (1 locale) Brazil = pt-BR Spanish (20 locales) es Argentina = es-AR Bolivia = es-BO Chile = es-CL Colombia = es-CO Costa Rica = es-CR Dominican Republic = es-DO Ecuador = es-EC El Salvador = es-SV Guatemala = es-GT Honduras = es-HN Mexico = es-MX Nicaragua = es-NI Panama = es-PA Paraguay = es-PY Peru = es-PE Puerto Rico = es-PR Spain = es-ES United States = es-US Uruguay = es-UY Venezuela = es-VE Simplified Chinese (2 locales) zh-Hans China = zh-Hans-CN Singapore = zh-Hans-SG Traditional Chinese (2 locales) zh-Hants Taiwan = zh-Hant-TW Hong Kong = zh-Hant-HK Japanese (1 locale) ja Japan = ja-JP Korean (1 locale) ko South Korea = ko-KR Group 2 = (12 languages, 13 locales) Czech (1 locale) cs Czech Republic = cs-CZ Danish (1 locale) da Denmark = da-DK Dutch (2 locales) nl Belgium = nl-BE The Netherlands = nl-NL Finnish (1 locale) fi Finland = fi-FI Greek (1 locale) el Greece = el-GR Hungarian (1 locale) hu Hungary = hu-HU Norwegian Bokmål (1 locale) nb Norway = nb-NO Polish (1 locale) pl Poland = pl-PL Portuguese (1 locale) pt Portugal = pt-PT Russian (1 locale) ru Russia = ru-RU Swedish (1 locale) sv Sweden = sv-SE Turkish (1 locale) tr Turkey = tr-TR Group 3 = (4 languages, 4 locales) Croatian (1 locale) hr Croatia = hr-HR Slovak (1 locale) sk Slovakia = sk-SK Slovenian (1 locale) sl Slovenia = sl-SI Romanian (1 locale) ro Romania = ro-RO
- #11: Platform support has been expanded for the 2.6 version to include AIX and Solaris. The installer has also been improved, and will do a lot of the WAS setup for you. Even setup database if installing in Cloudscape. Webform Server no longer supports the use of Tomcat (as it did in 2.5).
- #12: Webform Server requires you to write either a servlet or a portlet application. In either case, this application must both serve the form to the user and process the user’s response. The servlet/portlet extends the framework that is provided by Webform Server (rather than the normal servlet and portlet classes). As a result, Webform Server is able to automatically convert the form between XFDL and HTML when necessary. The servlet/portlet will automatically query the end-user’s computer to see if they have the Viewer installed. If they do, Webform Server will not translate the form – it will send XFDL so that the user can work in the more fully-featured Viewer. If they do not have the Viewer, Webform Server will send HTML for their browser. Webform Server also provides support for accessibility needs. This includes the enhanced focus indicator that the Viewer uses (a small black box that appears at the upper-left corner of the item that has the focus) and screen reading support for the JAWS screen reader.
- #13: Forms that are translated to HTML look almost exactly as they do in the Viewer. There are some slight differences because Webform Server uses standard HTML widgets, and in some cases those widgets differ slightly from the XFDL versions. However, for the most part it is difficult to tell the difference between the two forms. Just like the Viewer, Webform Server adds a toolbar to the form. However, because Webform Server has more limited functionality than the Viewer, this toolbar only has 6 buttons (described later). It’s worth noting that this duplication in appearance is entirely intentional. While it may be useful to render slightly different appearances in HTML, or to allow user’s to apply their own style sheets, this would defeat the “sign what you see” philosophy that underlies Workplace Forms. Essentially, forms that are signed in Webform Server should look exactly the same when inspected in the Viewer, and vice versa. If they did not, the overall security and authenticity of the form could be called into question.
- #14: Even complex forms look just like they would in the Viewer.
- #15: The toolbar offers the following functionality: Open Form – this opens a form from the local file system. In this case, Webform Server uploads the XFDL version of the form to the server. It then translates the form into HTML, and sends the user the first page. Save Form – this saves the form to the local file system. In this case, Webform Server sends the entire XFDL form to the user. This does not save HTML. Print Form – this prints the form to a local printer. In this case, Webform Server generates a PNG image of the form from the XFDL version, then sends the PNG to the end-user. The end-user then uses the normal browser print dialog to print the image. Toggle Accessibility Mode – this enables the enhanced focus indicator and screen reader support. The enhanced focus indicator is a small black square that appears at the top-left corner of the item that currently has the focus. Screen reader support is limited to the JAWS screen reader. About – this opens a dialog that provides version information for Webform Server.
- #18: The Pieces: Client – This is the end-user. In a typical scenario, they use a web browser to surf to a website that has forms they can work with. Portal/Application Server – This is the application server that hosts the servlet/portlet application you have built for Webform Server. Your application runs within the Webform Server framework, and may make calls to the Workplace Forms API. Application Server – This is the application server that runs the Translator component of Webform Server. This is the part that does the actual translation of XFDL to HTML. It can run on the same server as your portlet/servlet, but is more commonly placed on a second server. Access Control Service – This provides fail-over support for the system. The Access Control Service tracks which users are using which form instances, and ensures that in a clustered environment, the user can fail-over successfully. Logging Service – The logging services is used both by all other components: your portlet/servlet, the Translator, and the Access Control Service. It provides basic logging capabilities through log4j. Shared File Cache – This is simply a file area that is used by the Translator to store temporary files. When a form is opened by Webform Server, the original XFDL is stored and maintained in the Shared File Cache.
- #19: When you first try to open a form through Webform Server, the Framework first tries to determine whether you have the Viewer installed. This process follows these steps: A bounce mechanism sends a small piece of JavaScript to the client. This JavaScript contains a small XFDL form. The JavaScript asks the client browser to open the form. If the post is successful, then the Viewer is installed. If the Viewer is installed, the JavaScript examines the headers of the post to see if the right version of the Viewer is installed. The JavaScript sends the results to the Framework, which sets its own session flags accordingly. Once these flags are set for the session, no further attempts to detect the Viewer are attempted.
- #20: Next, the Framework carries out the original request as follows: The get request goes to the portlet/servlet. The portlet/servlet loads an XFDL form and sends it as the response. The Framework intercepts the XFDL response and forwards it to the Translator. The Translator converts the form to DHTML, and sends it back to the Framework. The Framework sends the response to the user.
- #21: When a form is submitted the following actions occur: The DHTML form is submitted to the portlet/servlet. The Framework intercepts the form when it comes in and passes it to the Translator. The Translator transfers the data from the DHTML form to the original XFDL form, then sends an XFDL response back to the portlet/servlet. The portlet/servlet processes the form and loads a response forms, which it sends back to the user. The Framework intercepts the response form and sends it to the Translator. The Translator converts the response form to DHTML and sends it back to the Framework. The Framework passes the DHTML form to the client.
- #22: Webform Server uses Ajax (Asynchronous JavaScript And XML) to communicate with the Translator for small updates. This allows dynamic updating based on formatting, type checking, computed changes to the form, and so on, without redrawing the form in the client browser. When an update event occurs, the following steps are taken: Ajax recognizes a user event on the client that requires an update, and sends an update request to the framework (or Forwarder Servlet in Portal). The request is read in by the Framework (or Forwarder) and forwards it to the Translator. The Translator replicates the event in the copy of the XFDL form it is running in memory, and retrieves the list of changes that need to be made. The Translator then creates a list of XML changes that are required, and sends that list back to the Forwarder. The Forwarder passes the change list through the Framework and back to the client. Ajax updates the HTML form as required.
- #23: Webform Server uses Ajax (Asynchronous JavaScript And XML) to communicate with the Translator for small updates. This allows dynamic updating based on formatting, type checking, computed changes to the form, and so on, without redrawing the form in the client browser. When an update event occurs, the following steps are taken: Ajax recognizes a user event on the client that requires an update, and sends an update request to the framework (or Forwarder Servlet in Portal). The request is read in by the Framework (or Forwarder) and forwards it to the Translator. The Translator replicates the event in the copy of the XFDL form it is running in memory, and this time sees that an XForms submit needs to occur. The Translator extracts the appropriate instance data from the form, and submits the data to the appropriate URL. The Translator receives the response, and places any new data in the form. The Translator then creates a list of XML changes that are required, and sends that list back to the Forwarder. The Forwarder passes the change list through the Framework and back to the client. If changes effect layout (create more items, remove items, etc), then page refresh is done. If changes are only to data, then no page refresh is done. Ajax updates the HTML form as required.
- #25: Multiple Shared File Cache’s helps limit the effects of a possible single point of failure. Where if the Shared File Cache went down in a single Shared File Cache architecture, the entire system goes down – compared to a system with 3 boxes, each box has 3 translators running, and each box had its own shared file cache (shared between the 3 translators on that box). If one of the shared file cache’s went down, the other 2 translator boxes would remain active and receive any new requests. Any current session in the failed file cache box would be lost
- #26: Typical scaling of Webform Server allows for replication of the servlet/portlet server, as well as replication of the Translator Server. For example, you could have one Portal backed by 3 Translators, or 3 Portals and 3 Translators, or any other combination. The Access Control Database may also be replicated. The Logging Service and Shared file cache are not typically replicated (although the Logging Service could be).
- #40: There are a few portions of this servlet that are not used by the example form. The code to handle an xforms-replace-all, for example, is not used by this form. If time permits, it is worthwhile to find or create a form that uses this code to demonstrate what it does.
- #45: In a normal Portal, you have several different portlets, some of which may need to communicate with each other. This is fairly easy to achieve using session beans. Each portlet can write to or read from these session beans as necessary, allowing them to pass information between each other. This is especially useful with forms. For instance, one portlet may need to tell another portlet which form to load. Or one portlet may need to pass some data to another portlet, which then populates the form it’s displaying with that data.
- #50: Opening forms from the local file system actually uploads the XFDL version of that form to Webform Server’s shared file cache. The form in the cache is then translated into HTML and sent back to the user so that they can work with it in their browser. Saving forms to the local file system actually downloads the XFDL version of that form to the user’s computer. The XFDL version is updated based on the user’s most recent changes to the HTML, then sent down as a single, up-to-date file. This allows users to route the form via email to other people, who can then re-open the form in Webform Server if required.
- #51: Form Layout : Forms may look slightly different in Webform Server than they do in the Viewer simply because the HTML widgets used to the draw the form may have slight differences from our standard XFDL widgets. However, in general it’s very difficult to tell the difference between the two forms. Webform server does not support certain widgets: Calendar widgets are replaced with date fields. The slider widget is not supported at all. RTF fields are replaced with plain text fields. Printing : When a form is printed, Webform Server first returns the HTML and updates the XFDL version based on the user’s most recent changes. Webform Server then uses the XFDL version of the form to create a PNG image. This image reflects what you would see in the Viewer. This image is then sent to the user, who sees the browser print dialog open. Because browsers impose their own margins on a printed page, the form might be scaled slightly to account for this, and may be a slightly different size than it would if it had been printed from the Viewer.
- #52: Type checking : All type checking in Webform Server is passive. This means that the checks are applied after the user tries to move the focus to the next item. Incorrect data is flagged as an error with a red color and a dialog that informs the user of the error. Attachments : Because you can only attach one document at a time, you may need to redesign your form to account for this. Forms that require the user to attach 20 documents may become very tedious through this interface.
- #53: Actions : Very limited, as described. Computes : Computes have been greatly improved over the 2.5 version. Through Ajax, they can now update automatically without a compete page redraw. However, this sort of update is not always possible, so those computes that still require a redraw will trigger the redraw automatically.
- #54: Submissions : Submissions will only send data to one URL. Version 6.0 through 6.5 of XFDL offered support for multiple URLs, but Webform Server does not reflect this. Version 7.0 XFDL restricts submissions to a single URL anyway. If you are computing URLs, make sure that your computes result in appropriate destinations. If using a servlet, your computed URL must go back to the same server that is hosting the servlet. If you are using a portlet, you cannot compute the URL. Email : Webform Server does offer direct support for email. There is no email button in the toolbar, and email buttons in the form itself (eg. Submit buttons with an email URL) will not work. If user’s need to email a form, they must save the form to their local file system, then attach the form a regular email.
- #58: Smartfill : You can write user data to/from disk using an XForms submit. This can replicate the behavior offered by Smartfill, but will not include the same user warnings that the Smartfill feature provided. For example, the user will not be warned that data is being written to disk or read from disk, unless you take special measures to replicate these sorts of warnings through other XForms functionality.
- #60: Web Services : Web Services are only supported in XForms forms. The submission data for a web service is wrapped into an XForms submit, complete with the soap envelope. When a response is received, Webform Server will replace a portion of the data model with that response, which will automatically populate the form with that data. Viewer Extensions : Viewer extensions are only supported on the client-side. This means that the extensions cannot perform tasks that would directly affect the user interface. For example, an extension cannot open its own dialog box. However, they can perform functions that indirectly affect the UI, such as setting values in the form that are displayed to the user.