Data management in hybrid rich and
Web client applications
Table
of contents Previous
Next
One benefit of a hybrid Lotus Notes and Web application is that both interfaces
access the same data store. The documents that you create in Lotus Notes
are visible to Web browsers and vice versa. However, Lotus Notes has 17
field types, and data that is submitted from the Web is, for practical
purposes, just text. Consequently, there are data management considerations
for hybrid applications that help avoid unexpected issues.
Because data submitted from the Web is text, numeric and date-time data
types in a hybrid application require special consideration.
A number field on a Lotus Notes form only
accepts numeric data. A Notes user can enter non-numeric data in a number
field but when the user attempts to save the document, the Notes client
shows the error message shown in the following figure.
Atempting to submit non-numeric
data in a number field using Notes
Likewise, if a form submitted from the Web contains non-numeric data in
a number field, Domino generate a similar error message as shown in the
following figure.
Attempting to submit non-numeric data in a number field using a browser
It appears that there is no problem. Domino prevents users from submitting
non-numeric data where a hybrid application requires a number. While this
is true, it takes a round trip from the browser to the server for Domino
to test the field value and inform the user of the error. We can make the
application more user friendly and save bandwidth by testing to see if
the field value is numeric using client-side JavaScript.
JavaScript contains a special value, NaN,
which is short for "not a number." We can use NaN to write a
function to verify a field value is numeric by using the isNaN() and parseInt()
functions as shown in the following example:
function isNumeric(input) {
   parseInt() and the parseFloat() attempt to return
an integer or a decimal respectively
  var x = parseInt(input, 10);
  if(isNaN(x)) {
    alert('"' + input + '"
cannot be converted to a number');
    isNumeric = false;
    return isNumeric;
  }
}
|
The isNumeric() function can be placed in the jsHeader of a form or an
externally referenced JavaScript library and called from the onSubmit event
or within a larger form validation function by using syntax similar to
the following example:
var f = document.forms[0];
if(!(isNumeric(f.NumberField.value))) {
  f.NumberField.focus();
  return false;
}
|
Each call to isNumeric() takes as a parameter the value of the field we
want to ensure contains a numeric value. If the field does not contain
a number, the user is alerted, focus returns to the field, and execution
of the form validation function ceases.
Dates
Like number fields, a Date/Time field in Notes
requires a valid date/time value or the Notes client shows the error message
shown in the following figure.
Attempting to submit an invalid
date/time value in Lotus Notes
Domino shows a similar error message (see the following figure) if an invalid
date/time value is submitted from the Web.
Attempting to submit an invalid date/time value using a browser
However, just as with number fields on the Web, allowing Domino to validate
a date/time value requires a round trip to the server, wasting time and
bandwidth when the field can first be checked at the client. Unlike a number
field, validating a date/time value on the Web is somewhat complex.
When attempting to determine whether a given
date value is valid, you must account for several factors such as the following
examples:
- Different months have differing numbers of
days, and in the case of February, a different number of days depending
on the year.
- Users in different countries may enter a
date in month/day/year format or day/month/year.
- There are at least three commonly used separators
in date values, a forward slash ( / ), a hyphen ( - ), or a period (.)
Because
of these issues, you sometimes see date values in Web applications that
are created by using three separate selection lists rather than a text
input field in order to minimize the amount of validation work required
as shown in the following figure.
Creating a date on the Web by using three
separate fields
The selected values are then combined to create a date/time value in a
hidden, computed field. However, this approach still requires client-side
JavaScript to ensure the selected date is valid (and not something like
February 31, 2008) to avoid an unnecessary round trip to the server.
As another option, the ever increasing number
of JavaScript frameworks now make it a simple exercise to add a DHTML "date
picker" to a Web page, similar to the one that can be displayed in
the Notes client as shown in the following figure.
A DHTML date
picker
The best approach for implementing time/date fields in your Domino application
varies based on your audience and the application requirements. The associated
code can be rather lengthy due to the multiple considerations involved
in validating time/date fields. However, the following links point to several
examples of browser based time/date field implementations and JavaScript
validation routines. A search for relevant keywords using the search engine
of your choice will undoubtedly yield additional examples:
If you have a hybrid application that uses rich text fields, you must be
aware of a couple of issues. First, if you create a rich text field on
a Notes form, the default option for rendering the field on the Web is
"Using HTML" as shown in the following figure.
Default option for rendering a rich text field on the Web is "Using
HTML"
On the Web, this translates to a text area and users are limited to entering
simple text as shown in the following figure.
A
rich text field displayed as HTML
Because a text area limits input to simple text, displaying a rich text
field on the Web by using HTML is probably the worst choice for hybrid
applications where documents that contain rich text fields will be edited
by both Notes clients and Web browsers.
 Attention
If a user edits a document in Lotus Notes and enters formatted text in
a rich text field that is configured to display on the web using HTML,
and the document is subsequently edited on the Web, all the rich text formatting
is removed. |
The second option for displaying a rich text field on the Web is "Using
Java Applet." Unlike a text area, with this option, users can enter
formatted text from the Web. Better still, if a document has been edited
in Lotus Notes and formatting is applied to a rich text field, Domino largely
preserves the formatting when the document is edited on the Web. Note that
100% fidelity is not maintained when editing a rich text field in both
Notes and on the Web, but it is close.
A rich text field displayed using a Java applet
The third option for displaying a rich text field on the Web is "Using
Best fit for OS." This option uses an ActiveX® control to display
the rich text field, but only in Internet Explorer. Users of other browsers
still see the Java applet.
A rich text field displayed in Internet Explorer "Using Best Fit for
OS"
If the browser users of your application use a mixture of Internet Explorer
and other browsers, you may want to avoid the "Using Best Fit for
OS" option so that users have a consistent interface when working
with rich text.
Developers have successfully incorporated
other WYSIWYG text editors for the Web, such as FCKeditor
and TinyMCE
,
into Domino Web applications. However these implementations are almost
exclusively for browser access only. Consequently, if your hybrid application
requires both Notes client and browser users to edit documents that contain
rich text fields, the best option in Domino 8.0.1 and earlier is to display
rich text fields on the Web by using a Java applet. Ensure that the
users of your application understand that there are limitations when editing
rich text using a browser and that they should avoid adding certain objects
to rich text fields by using a Notes client such as:
- Tables
- Images
- Ordered lists
The final issue related to data management you want to consider when developing
a hybrid application is whether users can add attachments to documents.
Using a Notes client, a user can create an attachment in any rich text
field. If the document is subsequently viewed by using Lotus Notes or a
Web browser, the icon for the attachment is visible in rich text field
the attachment was saved in as shown in the following figure.
An
attachment saved in a rich text field
The Web access display settings for the rich text field determine what
happens to attachments when a document is edited on the Web however. If
the rich text field is set to display "Using a Java Applet,"
any attachments that are already part of the document or added from the
Web are saved to the rich text field, although the formatting of the attachment
icon changes.
Saving the document on the Web modifies the display of the attachment
If the rich text field is set to display as HTML, the attachment is saved
to the document outside of the rich text field as shown in the following
figure.
An attachment saved as part of the document but not in a rich text field
Consequently, when dealing with attachments in hybrid applications, it
is best to have at least one rich text field set to display as a Java applet
on the Web.
 Important
If you have more than one rich text field on a form that is set to display
on the Web as a Java applet, be aware that any attachments on the form,
whether they were added by using Lotus Notes or a Web browser, and whether
they are attached in the first rich text field on the form or subsequent
rich text fields, are all saved to the first rich text field when the document
is saved from the Web. |