Search this site

Disclaimer

The "triDeveloper" site and content are neither affiliated with nor sponsored by TRIRIGA, Inc. "TRIRIGA" is a trademark of TRIRIGA, Inc. All trademarks used on this site are the property of their respective owners.

Spell Checker

Extending the TRIRIGA User Experience With Report Sections

Many users (for better or worse) rely on spell checking for their word processing documents, and come to expect similar functionality in all of the applications that they use.  While some web browsers now have a spell checker built in, Internet Explorer currently doesn't, and that's the browser typically used with TRIRIGA.  There are browser plug-ins that provide this functionality, but if we don't want to install anything extra on the client we can build our own web-based spell checker to integrate with TRIRIGA.  This will also give us a chance to look at some techniques for enhancing the TRIRIGA user experience.

For this example, we're going to use the following approach on the server side:
  1. A Servlet running alongside TRIRIGA periodically loads a dictionary (a simple list of words) from a file on the application server.
  2. The Servlet receives HTTP POST requests containing strings to be spell checked.
  3. The string is parsed into word units and lookups on the words are performed against the dictionary.  For each word that is not found, a list of suggested corrections is compiled.
  4. A JSON (JavaScript Object Notation) array is sent back in the response containing word suggestions.  Each entry in the array contains the misspelled word and its corresponding correction suggestions, as well as the position of the misspelled word within the original string.
The "heavy lifting" here is in step 3 above.  Fortunately, there is already an open source library, Jazzy (http://jazzy.sourceforge.net/), that can provide exactly this functionality for us.  In fact, there are several libraries that will support JSON encoding as well (http://www.json.org/), so we really don't need to do a whole lot of work.

On the client side, we will do the following:
  1. Grab the target content that we want to spell check; this would typically be the value of a text field.
  2. Submit an HTTP POST request containing the string to our spell checker Servlet, using XmlHttpRequest.
  3. Unmarshal the JSON response into a JavaScript array containing the misspelled words, their position in our string, and lists of suggestions for replacement.
  4. Prompt the user and provide them with the opportunity to apply each replacement, skip it this time, or skip it always for this page.
This is a lot more work, but we can factor out some of this.  Steps 2 - 4 can be generically applied to any page, so we can encapsulate that functionality into a small JavaScript library which we can reuse whenever we want to add spell checking functionality.  We can then serve that library script up alongside our Servlet, so the only situation-specific code is in step #1 -- obtaining the content on a particular page that we want to spell check.

To hook all of this into TRIRIGA, we're going to use a Report Section to pull in content from the Document Manager.

Using Report Sections

Report Sections are very useful GUI components that allow you to pull in HTML-based content from Document Manager as a "template", populated with content from the current record.  They are very similar to the Form Reports used in the Print Preview tab (or in the post-2.7 platform, the Reports tab).  Basically, you first create an HTML document to serve as a template; you then add "replacement tokens" which TRIRIGA will populate with record data at runtime.  For example:

Simple Form Report HTML

<html>
    <body>
        The ID of this record is %%General_triIdTX%%.
    </body>
</html>

When loaded in a Form Report (either through the Print Preview/Reports tab, or within a Report Section on a GUI), everything between the "%%" will be replaced with the corresponding field from the record.  You can determine the correct field strings to use by selecting the GUI in the GUI Builder and clicking "Report Header"; after selecting the desired fields in the popup window and clicking "Export" you will be prompted to download a ".doc" file (which is actually an HTML file, not a Word Document).  You can then use that as a basis for creating your HTML file, or just use the tokens within an HTML file built elsewhere.

This is itself quite useful, but more importantly we can use the Report Section to pull in arbitrary HTML content that we want to display within a GUI.  This allows us to build mashups and other dynamic extensions.

Building The "Spell Checker" Section

In this example, we're going to leverage a few features of how GUIs work "under the hood":
  • Report Sections are actually simply IFRAME elements within the GUI form, which load the rendered HTML from Document Manager;
  • Text fields are simply INPUT and TEXTAREA elements on the GUI form itself; and
  • Note fields are IFRAMEs which load the note content into a "subpage" with the contentEditable property set to allow rich text editing.
So for our spell checker Report Section, we're going to create a small HTML file containing JavaScript to do the following:
  1. Examine the parent frame (remember, the Report Section is loaded in a child IFRAME, so the parent is the GUI form itself), and look for any TEXTAREAs,  INPUTs with a type of text, and IFRAMEs with a contentEditable property set to true.
  2. For each qualifying item found, we will add an "onkeydown" event handler that looks for the F7 key; that will be our trigger to spell check that field.
  3. If the user presses F7, we will simply invoke our spell check library on the field.  Additionally, if the user presses SHIFT+F7, we will have it check all fields on the form.
Obviously, we don't want to have a big "Spell Checker" section on all of our GUIs, so when we add the Report Section we will stick it at the bottom of the GUI tab, uncheck the "Show Title Bar" setting, and specify a Height of 1.  That's pretty much it; the HTML form is reusable, and should work with little or no modification on most GUIs.

One important caveat -- while the spell checking library is essentially a pluggable drop-in (there's nothing TRIRIGA-specific about it, you could easily add it to any other web-based application), the "hooks" into the GUI are highly dependent on how TRIRIGA renders a GUI form.  In other words, if 2.8 is released and implements GUIs in a radically different way, it's highly likely that the spell check will no longer work correctly.  At that point you'd need to rewrite the HTML/JavaScript file to accommodate the changes.

Additional Resources

The source code for the solution presented in this article is available at the triDeveloper code repository:


Files