Using SpellServer


SpellServer Overview

Chado SpellServer is a COM object that provides your Active Server Page-based web application with a ready-to-use spell-checking engine.  It uses an extensible 135,000 word English dictionary, with additional languages available as an upgrade, including UK English, French and Spanish, as well as a Medical dictionary.  It is a multi-threaded DLL, capable of supporting multiple simultaneous users, each with their own custom dictionary, as well as ignore, change-all and ignore-all lists.  SpellServer is configured to run as an MTS component.


Using SpellServer in ASP

SpellServer is a COM object that provides a number of methods and properties that can be used to check spelling in an ASP environment.  Simply having an object isn't enough, so we provide two complete working ASP applications that show how to use SpellServer - one that uses Sessions, and one that doesn't.  You can examine these sample applications and use them as examples while writing your own application, or you can easily integrate the main ASP spell checking page from one of the samples into your application.

Both sample applications are comprised of three pages:

InitialPage.asp The initial data entry page.  This page will typically be replaced by a page in your current web application, as it serves only to collect the text that should be checked.  Our version allows you to easily change values for various spell checking options, but those options would typically be set manually in your code.
Correct.asp The main spell checking page in the application.  This page uses SpellServer to search for the next misspelled word, and then to present that word, its suggested replacement strings, and various possible actions for the user to take.  When the entire string has been spell-checked, this page forwards the user to the next page of your application (in the case of this demonstration, we use the Finished.asp page).
Finished.asp This page serves only to display the final results of the spell-checking.  It will always be replaced with your own page (one that continues processing with the now spell-checked text).


Integrating Correct.asp Into Your Application

The main page in the sample application is Correct.asp.  This page can easily be integrated into your own application by following these steps:

1.  At some point in your existing application, you will have some text you wish to spell-check.  Perhaps your application allows the user to enter text into a text box, or maybe you retrieve or construct some text based on user input.  At the point that you've assembled or collected the text, you need to pass this text into the Correct.asp page by posting the data as form data, using a field called FullText.  If you wish to change the name of this field (perhaps because you are posting from a field in another page), simply change the references in Correct.asp to use the correct name.

2.  Once you've got the text into Correct.asp, you'll need to modify Correct.asp so it has the spell-checking options set the way you wish them to be.  These options include ignoring words that are ALL CAPS, or that appear to be HTML tags or special characters, setting up the custom dictionary, removing undesirable words from the dictionary, and other actions.  There are comments in the Correct.asp file that indicate which section of code you need to modify.

Currently, Correct.asp is set up to retrieve the spell checking options from form data.  This is for the example code, so you can easily test the behavior of SpellServer when you change different options.  Typically, in your own code, you would hard-code these values.  To change correct.asp, look for the block of code that retrieves the variables that begin with the characters "bIgnore" (for example, "bIgnoreAllCaps", "bIgnoreCase", etc).  Additionally, these values are currently posted as form data - once they are hard-coded, simply remove the hidden input tags that do this.

3.  Modify Correct.asp so it posts the final result to the next page in your application's logic flow.  For the purposes of this example, the results are redirected to Finish.asp, but you'll probably want to store the corrected string somewhere, depending on the needs of your application.

4.  Modify the styles used by Correct.asp, by changing the style in the code itself, or by adding a <LINK> tag to point to your own CSS file.


Which Interface Should You Use?

SpellServer 1.0 used Sessions to store context information.  SpellServer version 2.0 introduced the SessionlessEngine interface, which was specifically designed to be used when the use of sessions was not desirable.  SpellServer still supports the Engine interface, which uses Sessions, so existing ASP applications that were designed with an older version of SpellServer will continue to work correctly.  (If you are using SpellServer as part of a non-ASP application, feel free to use either interface.)

So, what are the advantages and disadvantages of each interface, and how do we access them?  The following table explains:

  Engine SessionlessEngine
Advantages Much of the context information that SpellServer uses is kept in memory, reducing the amount of data that needs to be passed from page to page. No sessions are needed, which reduces memory usage on the server.
Disadvantages Requires a session variable to store the SpellServer object, which prevents use in various situations, including clusters of web servers. Each time the spell checking page is loaded, it must reset all of the checking options, including the custom dictionary, any words flagged as Ignore-All, etc.  This may reduce performance.

All of the context information that SpellServer uses must be passed from page to page.

You need to call CreateObject each time the page loads, in order to load the SpellServer object.
How to Invoke set objChecker = Server.CreateObject("ChadoSpellServer.Engine") set objChecker = Server.CreateObject("ChadoSpellServer.SessionlessEngine")



Custom Dictionaries

A custom dictionary is a set of new words that are added to the base dictionary that is built into SpellServer.  A custom dictionary may be nothing, or it may be words added by the web application, words added by the user, or a combination of words added by the web application and words added by the user.

When dealing with custom words that you want added to every user's dictionary, there are two ways to get the words into the SpellServer object.  First, you can load in words via a string (either a string constant, or loaded from a table or file of your own) passed to the AddToCustom method.  This method is somewhat slow, and is best suited for small lists of words, or for lists of words that change often.

The other approach is to compile a list of words into a Compiled Custom Dictionary (CCD) file using the included Custom Dict Compiler application.  Once a CCD file is created, it is loaded by a call to LoadCCD method.  Multiple CCD files may be loaded at once.

Our example ASP pages use a simple string constant to load a custom dictionary, but in your application, it will probably be read from a file or a database.  Once the company's custom dictionary is loaded, the example appends user-specific custom words, which are stored in a cookie on the user's machine.  Once the spell-checking is complete, we remove the company-specific words from the custom list, leaving only the user-specific words, which we then write into the cookie on the user's machine.  This technique allows you to create a fixed list of custom words that all users have access to, and, at the same time, allows users to add their own custom words, which are saved in a cookie on the user's machine.

When adding words to your custom dictionary, keep the following rule in mind:  If a word must be capitalized, like "Michigan", then make sure it's stored that way in the custom dictionary.  If a word can be used either as lower-case or upper-case, like "the", then store it as lower case.

In terms of speed, words that are stored in the custom dictionary are retrieved just as fast as words stored in the base dictionary.  As stated above, the speed of loading a CCD file is much, much better than loading a custom dictionary via a call to AddToCustom method.


Deployment

Deploying SpellServer is fairly straight-forward.  Simply register ChadoSpellServer.dll on your server by using REGSVR32.EXE, and make sure that ChadoSpell.dll is located in the same folder.  If you are using a language other than US English, then you'll need to register the appropriate DLL file, and make sure that your Correct.asp refers to the correct CLASSID (see the code).

Once you've purchased SpellServer, there is one additional step you must follow in order to get SpellServer working properly.  When you purchase SpellServer, you will receive a license key via e-mail.  In your ASP code (in the Correct.asp file), set the LicenseKey property to this value, which is a string.  This is a required step.  Failure to do this will cause SpellServer to generate an error message.


Checking Multiple Fields

Occasionally, you may wish to spell-check multiple text fields.  This adds a layer of complexity to any ASP code you are writing, but it certainly is possible, providing you keep the following items in mind:

First, you need to check one field at a time.  From a user interface perspective, it's crucial that your users know which block of text they are currently spell checking.  You may wish to include some sort of text identification somewhere on the correction form to show them what piece of text they are currently working on.

Secondly, you'll need to modify Correct.ASP to keep track of which piece of text you are checking at any given time.  A numeric index might be the best approach for this.  This way, when one piece of text is completely checked, the index of the text to be checked is incremented, and the next field is loaded into SpellServer.

At that point, you'll need to reset the StartCheckingAt property (if you are using the Sessionless interface) to 1, and set the StringToCheck property to the new string to check in order to re-initialize checking.  You'll probably want to keep the custom dictionary the same, as well as the Ignore-All list, since it's unlikely that a user would want those changed from one field to the next.


Different Languages

The base version of SpellServer checks spelling using a US English dictionary.   There are additional languages available included in the installation, including UK English, Canadian English, French, Spanish, and a Medical dictionary.   Each of these versions of SpellServer has a unique GUID COM ID, which means that you can load different versions of SpellServer at the same time.

Make sure you are loading the correct version of SpellServer via this table:

COM Object Creation (Sessionless Interface)Language
set Checker = CreateObject ("ChadoSpellServer.SessionlessEngine")US English
set Checker = CreateObject ("ChadoSpellServerUK.SessionlessEngine")UK English
set Checker = CreateObject ("ChadoSpellServerCan.SessionlessEngine")Canadian English
set Checker = CreateObject ("ChadoSpellServerFr.SessionlessEngine")French
set Checker = CreateObject ("ChadoSpellServerSp.SessionlessEngine")Spanish
set Checker = CreateObject ("ChadoSpellServerMed.SessionlessEngine")Medical
COM Object Creation (Sessions Interface)Language
set Checker = CreateObject ("ChadoSpellServer.Engine")US English
set Checker = CreateObject ("ChadoSpellServerUK.Engine")UK English
set Checker = CreateObject ("ChadoSpellServerCan.Engine")Canadian English
set Checker = CreateObject ("ChadoSpellServerFr.Engine")French
set Checker = CreateObject ("ChadoSpellServerSp.Engine")Spanish
set Checker = CreateObject ("ChadoSpellServerMed.Engine")Medical


Technical Support

Chado Software stands behind its products.  We offer free lifetime technical support for our products (details are available on our web site).  Be sure to check our web site for updates to SpellServer and new technical information, and also use it to contact our technical support team if needed.

www.chado-software.com