Since your browser does not support JavaScript, you don't see any navigational toolbars above. For now, please use the navigational links offered at the bottom of each page. We are working on a better solution.

TEXTAREAFORMAT Custom tag and UDF

By: Charles Arehart, SysteManage, carehart@systemanage.com

Created: 2/7/99
Updated: 2/15/99, 7/26/00, 1/28/05

Purpose:

The TEXTAREAFORMAT UDF and custom tag are an enhancement over the features offered by the CF paragraphformat function and/or the HTML pre tag. Either can be used when you want to display to a user the data that has been entered into a TEXTAREA form field.

The Problem

TEXTAREA form fields are very useful, since they allow multiple lines of data to be entered. They also can be deceptive. A user can press the "enter" key to create new lines, or press enter twice to create blank lines. Spaces can also to be entered, if needed. And if the user copies text from another source, even tabs can be used within a textarea field (if the user tries to simply press the tab key, however, the cursor just jumps to the next input field).

That's all wonderful, until you try to show that input to the user in a subsequent page. Have you evered try to display such textarea data, such as for their review on the form's action page. Or, more likely, have you stored that data in a database and then tried to display it again later to the user, perhaps in a report?

The problem is that, when you display the field within a CFOUTPUT or CFOUTPUT QUERY loop for example, the user's input is not accurately rendered. All those wondeful carriage returns, spaces, and tabs are lost! Well, they're not lost. But they'll be ignored by the browser, since browsers just naturally ignore those things.

What we need, instead, is to convert all those things into the HTML that will be properly interpeted by the browser. We want single enter key presses (stored in the field as carriage returns) to be converted to tags, and double enter key presses (stored in the field as 2 carriage returns) to be converted to tags. We also want to convert multiple consecutive spaces to be converted to the &NBSP (non-breaking space) character and any tabs to be converted to 8 non-breaking spaces.

But do you want to do that conversion? Searching for each such "bad" character and change it to the proper HTML version? Why bother. There is another solution: TEXTAREAFORMAT!

Sometimes, you don't even notice this problem because as long as the user hasn't used blank lines, spaces, or tabs, the TEXTAREA field is accurately rendered on output. But that doesn't mean someone won't do it someday. It's just too easy, and using blanks, spaces, and tabs can be very useful for making the input more well-organized.

The bottom line is that you NEED to put a solution in place, so that when the data is displayed back to the user, it's rendered accurately.

An Inelegant Solution

One solution is to always display the data in a TEXTAREA format field again, but that's usually not appropriate if your intending only to show it to them for output, since the user would be given the impression that they could change the data.

Of course, if the user is going to be offered the opportunity to edit the data, this is indeed the solution, and you don't want to use any of the solutions below.

HTML's semi-solution

HTML offers the <pre> tag, and you may think that solves this problem, but for one thing, it uses a courier-style font to show your data, which is ugly, and worse, if you have any very long lines, those won't wrap and will ruin your lovely screen display by making any right nav bar or other content disappear!

CFML's semi-solution

CFML offers a partial solution in the PARAGRAPHFORMAT funtion. It's almost does just what we want. Unfortunately, it only does half the job! It converts converts double carriage returns to a tag, but it does not convert a single carriage return to a , nor does it convert multiple consecutive spaces to non-breaking spaces ("nbsp"), nor TAB characters into some fixed number of non-breaking spaces (since there's no "tab" characters support in HTML). As such, PARAGRAPHFORMAT does not present an accurate representation of what a user has typed into a form's TEXTAREA input field.

The Best Solution: TEXTAREAFORMAT

TEXTAREAFORMAT, on the other hand, solves all four problems:

converting single carriage returns (where the user pressed "enter" in the TEXTAREA field) into tags
converting 2 carriage returns (where the user pressed "enter" twice) into tags
converting multiple consecutive spaces into &NBSP (non-breaking space) characters
converting TAB characters into a fixed number of non-breaking spaces

All you need to do is pass the field to be formatted to the UDF or custom tag, and in return you'll receive a formatted string that you can then display to the user. Basically, you use it on a form action page when you intend to show the user's input to them for review, or you use it on any page that's displaying query data that includes data that came from a textarea field.

Syntax

Syntax details and code examples are available separately.

Live Example

See the available live example for a working demonstration of displaying a textarea field and the difference between showing it with no formatting, formatting it with Allaire's paragraphformat function, and formatting with CF_TEXTAREAFORMAT.

USAGE NOTES:

The choice to have this custom tag convert any 3 consecutive spaces into non-breaking spaces was made so that single and double spaces, common in writing, are not converted. And the conversion of tabs to 8 spaces is arbitrary. It reproduces an approximate spacing created by a tab.

Note also that you don't want to use the converted data (the output of TextAreaFormat) for storing the data in a database. It's perfectly ok to store the TEXTAREA field data directly in a database. The carriage returns, spaces, and tabs will be stored just fine. It's only when you later display it to a browser that the problem arises. We just need to convert it whenever we want to display the data, whether on the form's action page or later in a query report.

Return to the Main CF_TEXTAREA Page.

If you have any questions, please send them to carehart@systemanage.com.

Further details available for: