In the last minute, I have added a spell-checking facility to the form builder and 5.0. I think you'll need a little description of it ...
Spell-checking may be engaged on individual form elements where the type of widget is either text, textarea, or richtext.
If you update your check-out of HEAD, you'll notice that spell-checking, by default, is enabled on all three of those types of elements in all the forms that have been built using ad_form or form builder proper, although the radio buttons only defaults to "Yes, please spell-check" on textarea and richtext elements.
If, let's say, you don't agree with the decision that text elements should be possible to spell-check, you can simply remove that possibility by changing the SpellcheckFormWidgets parameter under acs-templating. The parameter works like this:
In case you want to be able to spellcheck all the possible widgets you enter the string "text 0 textarea 1 richtext 1", for instance (this is the default). The boolean behind each widget decides whether the default choice to actually perform any spell-checking is "yes" or "no", i.e., which of the two radio buttons should be selected by default ...
If you decide to turn of spell-checking on the site altogether you can do that by leaving the above parameter blank and the "yes"/"no" radio buttons will go away in all the forms.
I have also introduced a new flag, "nospell", to ad_form and template::element::create, which lets you override the site-wide instruction to present spell-checking as an option for certain elements. For example, we might want to use the nospell flag on the fields in the register form and the parameter pages.
The nospell flag is used like this (from the ad_form documentation I added):
{email:text,nospell {label "Email Address"}
{html {size 40}}}
Define an element of type text with spell-checking disabled. In case spell-checking is enabled globally for the widget of this element ("text" in the example), the "nospell" flag will override that parameter and disable spell-checking on this particular element. Currently, spell-checking can be enabled for these widgets: text, textarea, and richtext.
There are two more parameters connected with the spell-checking feature. One is SpellcheckerPath for the aspell/ispell binary path and it defaults to /usr/bin/aspell (which is where Debian, my favorite distro, puts the aspell binary 😊. The other parameter is SpellcheckLang for the dictionary locale (empty string uses aspell's/ispell's default dictionary). Depending on the distribution you're using, you may have to install aspell/ispell. I have a feeling aspell is superior to ispell, but I don't know for sure.
There are at least two issues with the spell-checker that I am aware of, which we'll have to fix over the coming weeks, and they are:
- With richtext, when using HTML format or enhanced text format, the error page with the text with select boxes for the suggested replacement words is complaining about unacceptable <select> tags. I'm not sure if it's possible to work around this while still generally not accepting that tag in the toolkit as a whole(?).
- A very strange regsub related (probably) error in the errwords replacement code in the actual spellcheck proc (template::util::spellcheck::get_element_formtext) where some of the error placeholders (#errnum#, etc) are not being replaced. But it works 90 percent of the time :-b
/Ola
