[Looking for Charlie's main web site?]

Several useful web dev topics, "Better Explained"

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I happened upon a site today with many quick, to the point, highly graphical articles introducing web app development topics that may interest some of my readers. Wanted to pass them along:

A few focus on Javascript and/or site building:

Still others aren't specific to web development, but can be valuable to all kinds of developers, and it was one of these that led me to the site in the first place:

The site is Better Explained, whose tag line is "Explanations for everyone". The author does a pretty good job of that. Some of the topics are a little too one-sided (the discussion of HTTP compression does only show setting it up in Apache, not IIS), and of course there's no mention of CF anywhere. :-) But we can't expect that from everyone. There are lots of positive comments and linkbacks on on many of the entries, so he'd done a good job in the eyes of most.

Indeed, if you may be hearing the siren call of Ruby on Rails, they have an article on that: Starting Ruby on Rails: What I Wish I Knew. There's also an intro to MVC, but again it's from a Rails perspective: Intermediate Rails: Understanding Models, Views and Controllers.

If there's something you'd like to see the author address on the site, he has a post for that, too: What do you want Better Explained?.

Setting Google to Show You More Results Per Page: how and why

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
In a recent entry, I made mention of the fact that I have Google set to show me 30 results per page, rather than the default of 10.

Some may read this and say, "big deal, I've been doing that for years", but it's one of those little things that some just never notice or think of. If you've not considered the option, why not check it out?

(Update on 9/30/2010: Others may have noticed that they DID have it set to more than 10, but recently they lost that functionality. I have the solution for that, as well.)

Others may say, "well, why choose to see more than 10? They offer buttons to let you page through the results", but the point is that people often will not page through them. I can tell you from my own experience that seeing more than just those "top 10" results when searching makes me more inclined to quickly consider more results. More on why do it in a moment.

How to make the change

The change it really simple. Just click the "Search Settings" box to the right of the top of the search page at google.com. (It used to appear to the right of the search box as a "preferences" link, but now it appears at the top right instead.)

If you're logged in, it will instead show as a link to "Settings", with "Search Settings" as a menu option under that when you click on it.)

On the preferences page, the 4th option controls the number of results.

Sure, they warn that 10 results per pages is "faster", but in these days of high speed internet, that's of course a relative assertion.

Update on 9/30/2010: Need to turn off Google Instant search

As I noted above, some may have noticed that even with that setting set, and saved, they still see only 10 results. In fact, if you re-open the preferences page, you'll see that it just ignored your choice and is back to 10. What gives?

The problem is the new "Google Instant" search feature, implemented recently (by default), which allows search results to appear as you type in your search criteria. If that's enabled, then Google does not let you set the results to more than 10. That's a shame, but worse is that they don't warn you of this when you try to change the number of search results.

The setting appears two below the "number of search results". Choose "Do not use Google Instant", if you want to see more than 10 search results.

Sadly, if you try to change both settings at once (turn off "Google Instant" and change "number of results"), that doesn't work either for the same reason above. Instead, do it in 2 steps: turn off Google Instant, save the preferences, then edit them again and change the number of results, and save that.

It really is too bad that Google doesn't handle both problems more gracefully.

Why to make the change to see more results

So why make the change to see more results? We all tend not to want to page forward through search results, right? But often some of the best results--those with real valuable info--are beyond the top 10, perhaps just beyond them, or perhaps 30 or 40 down.

Of course, hucksters know that people are reluctant to page down and go to great lengths to get their stuff in the top 10. (Granted, there are many fine entries which also show up in the top 10 just because they deserve to.)

But if you set your results to 30 at a time (or some other number larger than 10), you're just more likely to find (or consider) other results. It's surely paid off for me, and the speed to show more results is hardly noticeable.

Also, seeing 30 at a time makes it feel like no problem to go through a hundred results (including following the link to look at some of them) in a matter of minutes. Just something psychological about feeling that paging forward a couple of times is no big deal, but I see a lot more results doing that than if it was set to 10.

(And given the conflict with "Google Instant" discussed above, I'm happy to forego that feature to see more results instead.)

Hope this may help some of my readers.

PS Oh, and if you have changed the Google preferences but find your browser keeps losing the changes over time, check out the other recent entry I referenced at the top here, which addresses this very problem.

Been losing cookies from sites you visit? Fix in FF 3.0.7, and solution for other browsers

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
If you use Firefox and have found it losing cookies, this will interest you. Even if you don't use FF, and experience the problem on Chrome, IE, Opera, Safari, etc., the root of the problem and a possible manual solution may interest you.

Of browser point releases, why it's worth paying attention

So Firefox 3.0.7 landed on my machine today as an auto update. Like me, you may find that these point releases aren't too much to write home (or blog) about. Often it's things like adding "Estonian, Kannada, and Telugu" language support. No offense to them, of course, but it's not something to get me get excited.

Still, I watch the release notes whenever a new release is pushed (just like I comb more carefully the far more interesting release notes for any new CF release), as you never know what surprise may be in store.

A fix in FF 3.0.7 seems the solution

Today, my reading the release notes paid off. There's word of a fix to the problem that's the subject of this blog entry:

"For some users, cookies would appear to go "missing" after a few days (bug 444600)."

Well heck yeah. It's been really annoying. And reading into that also showed how to solve the problem in other browsers.

What I was experiencing

Just like those in the support team (discussing the problem in the bug note), I would find that every couple of weeks various sites I visit often would have lost their cookies.

For instance, I set my Google search result preferences so that I see 30 search results at a time, rather than the default of 10. Suddenly it would be reset, which was very noticeable.

Or my bank would suddenly act like I'd visited the site for the first time on my laptop (when I'd used it just last week), and it make me go through extra authentication. That was annoying.

I knew it had to be a problem of the cookies being lost, but none of the obvious things were the problem. It was a nuisance, but not the end of the world.

The problem was not caused by what fellow troubleshooters may presume

Before pointing out the solution, I'll note that some may put on their debugging hats and wonder about what might have been other possible causes. It would have been easy to suspect a lot of things when faced with this problem.

Was it that the cookies being set (and lost) just had a suddenly early expiration date? Well, no, that wasn't it. (And these were major sites, like Google, my bank, etc. They don't make such mistakes, at least not more than once, typically.)

You might wonder if it was something I was doing on my system. No, I wasn't clearing out cookies. I just don't have call to do that, though I know some do when facing some development challenges.

I also don't regularly run any tools that might have been doing this for me, such as registry cleaners, anti-virus tools, etc. (And no, I don't run an AV tool all the time, and I've never suffered for it. I'll blog about that in a future note.)

So, sure, good to do the diagnostics. And an A for your effort, but it wasn't the problem. (BTW, this troubleshooting and helping people think through problems and use diagnostics is indeed what I do for a living now, helping people solve problems related to CF, so I really do respect and appreciate those who try to solve things on their own first. But if you do that and still have a problem, or can't take the time or don't know where to look, I can help.

The root cause, and learning more

So, back to the fix, it's great to see this it may well have been due to this issue now recognized and fixed in FF 3.0.7, which basically comes down to a combination (explained well in the bug note) of both a low default for how many cookies FF should keep (1000) and an eviction algorithm that didn't take into account how recently you'd visited a site before kicking it out when the limit was reached. Very nice.

You can learn more about the release, and get it if you've not auto-received it yet, here.

Oh, and if you want to up the number without applying the fix, the setting is called network.cookie.maxNumber, and you can tweak it using about:config (in FF), to access the underlying configuration settings.

As always with such tweaks, be careful. And naturally, raising the limit could eventually cause FF to take up a little more space in its repository to hold permanent cookies, and in memory. The bug note reports an estimate of about 1-2m per number increased, FWIW, so forewarned is forearmed.

What if you're not on FF?

As for those using Chrome or other browsers, note that you may find the same default setting of 1000 is limiting you. Whether and how to set it may vary, of course. Chrome, for instance, offers no about:config or other seeming way to edit its config settings (correct me if that's changed.)

I looked briefly and couldn't find how to set this in IE, Safari, or Opera, but if anyone reading this finds it, please share as a comment.

A couple of bonus tips

A couple of final observations: the bug note talks about how to get an interface tool for querying the underlying SQLite database, including SQL statements for detecting most recently accessed cookies,etc. Interesting to explore.

I also wanted to talk about an interesting observation from seeing discussions that took place from people trying to solve this problem. It's an interesting case study in troubleshooting and where one can go wrong. And I wanted to explain why changing the Google preference from 10 to 30 is a good idea. This has gotten way long, so I'll write those up as separate entries.

Helping Joe Rinehart and his wife Dale

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
While some may have seen this news in the past weeks, it bears repeating for some who may have missed it. Joe Rinehart's been a stalwart member of the CF community for some years, known most perhaps for his work on the Model-Glue framework.

Well, sadly, his wife Dale has been diagnosed with Multiple Sclerosis, something he's made public on his blog. In addition to his sharing his experience there, she's has been journaling her experience and emotions on their blog. I'm sure many are finding comfort in their incredible strength and fortitude in the face of such a trying experience.

Still, the costs for treatment will be monumental, and so a group of CF community members have gotten together to create a site, www.helpsupportjoeanddale.com offering a way for those interested to offer donations to help offset those costs. So far the collections have been going really well, and all the money goes to them directly.

You can even watch a short video at the bottom of the page where Joe and Dale express their appreciation for this outpouring of support. All this was a surprise for them, and it's been a touching testament to the greatness of this community. I wanted to wait a couple of weeks to put the news out there again for those who may have missed it the first time.

Wanna a new feature/fix in CF? Report it on the CFWISH form...just don't search for it by that name

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Since writing this blog entry in 2008, Adobe has now opened up access to bug tracking for both CF and CFBuilder. So rather than use the old "wish form" below (which still works but does not give you a tracking number), use instead:

CF Bug Tracker (or also at adobe.com/go/cf_bugs)

Besides giving you a tracking number, you can also search these bug bases, as well as vote and comment on bugs offered by others. Finally, if Adobe addresses your bug, you'll be notified by email of that.

Many may know that Adobe has long offered a Feature Request/Bug Report Form form (which came really from Macromedia, and perhaps even Allaire), but for those who don't, I wanted to mention it here, for a couple of reasons.

First, we're on the cusp of a new release (Centaur/CF9), so now's the time to get your ideas in. :-) Second, if you need to find it, you may struggle if you search for it as "cfwish". More on that in a moment.

Of course, another way to get involved in the next release is to apply for the prerelease program (which has its own different bug/feature reporting form). More on that program in a moment, too. And I'll note that while this is a page for reporting features/bugs on all Adobe products (not just CF), it's also not a true bug tracking system (more on that in a moment, too).

Hoping this makes it easier for people to find

First, as for this public form, even those who do know about it may find it hard to find (via searching) when they need it (if they've not bookmarked it).

Part of the problem comes from the fact that the URL for this form includes wishform, and some may then connect that in their mind (as I did) with the term "cfwish". Sadly, a Google search for that won't find a link to the form above; instead it will find references to pages mentioning email addresses that used to be used in the past to submit such requests: [email protected] and [email protected] Those, of course, are no longer useful.

But even a search for "coldfusion feature request" didn't find a link to the form within the first 30 Google results (though a search for "coldfusion bug report" found it first). Until Adobe might put wording on that form to make it be found for these keywords, I'm hoping that perhaps this entry may be picked up to more readily to help people find the form. :-) Of course, you can find links to it from the Adobe site, too.

Hope for an Updated Bug Tracker

Some might say I was remiss in pointing people to that form without recognizing that it's not perfect. There's no real tracking of items: you don't get any sort of tracking number (I'm referring to the public form above, not the beta form), and there's no way to list all items you've submitted. Of course, you also don't get to see the items others have submitted, nor can you vote on them, etc.

The subject of an updated bug tracker has been discussed many times, such as here, and as mentioned in a comment there, Adobe has said that one is coming. Some have noted that Adobe already has a better bug tracking system, at http://bugs.adobe.com/, and it would seem that could be easily opened for CF, but so far, no go.

Consider also registering for the Centaur beta

Of course, if you really want to get involved in forming the next release of CF (Centaur/CF9), note that applications for the prerelease program are now being taken. Again, prerelease programs have yet another feature/request form, as well as discussion forums. That's about all I can say, and I'm hoping no one will mind me saying even that. "What's the first rule about betas? You don't talk about participation in betas."

One last point: I should note that there has for several years been yet another CF bug reporting alternative: http://cfbughunt.org/. Unfortunately, at least as of this writing, it does not seem to have been updated for quite a while.

Kids these days, rowdy like it's 19... um, 399AD

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
A teacher writes that he moved to a new city because he heard the students there were much less rowdy than in his former school, where they would "burst in rudely [into a random classrooom] and disrupt the discipline which the teacher had established".

Of course, we take it as a given that this could happen in many places today, but what's interesting is this isn't an account from today, or yesteryear. Not 100 years ago, nor even 1,000 years ago, but the late 4th century AD!

I was persuaded to go to Rome and teach there [because]... I had been informed that the students there studied more quietly and were better kept under the control of stern discipline, so that they did not capriciously and impudently rush into the classroom of a teacher not their own--indeed, they were not admitted at all without the permission of the teacher. At Carthage, on the contrary, there was a shameful and intemperate license among the students. They burst in rudely and, with furious gestures, would disrupt the discipline which the teacher had established for the good of his pupils.

This is from Augustine's Confessions, an autobiographical work (more than that, really) regarded as one of the earliest in western civilization. Of course it's an English translation of the original Latin, but boy, it sure sounds like things haven't changed.

So next time you want to lament "kids these days", just know that it's not really all that much worse than in times past. Sure, there have been periods where calm and discipline may have reigned, but sadly it's human nature to degrade to chaos. The gist of the work is about the guiding hand that causes this pendulum to swing to and fro.

Even if you don't agree with his premise, it's still an often fascinating glimpse into redemption from a debaucherous life 1600 years ago, from Augustine's pulling pranks as a child to gain acceptance, to falling in with the wrong crowd as a teen and stealing things just for the thrill, to dropping out of school, later shacking up with a girlfriend unmarried for 11 years, and so on. He turns out well in the end, to the extreme, so there's hope. As one who did at least a couple of those things myself, I can surely relate.

But my main point is that we tend to look on the past with rose-colored glasses, as if they were always simpler, more innocent times, so unlike ours, and that today is a time of unprecedented declining moral values. "Sure", we figure, "those were tough times, with wars, pestilence, disease back then", but we assume we've moved beyond with modern culture, intelligence, reason, etc.

I just think it's pretty eye-opening to get a chance to peer into a time capsule like this from so long ago, to see a day in the life as it were, partying like it was 19..., um, 399 AD.

PS For folks interested in the book but who prefer to listen to it, there are many recordings, including a free offer back in August. Of course, it's probably available in audio in most library systems, too.

Adam Lehman in car accident in London, recovering

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I just heard news of this on a private list and when searching could find only one entry with confirmation and a few details, so I wanted to pass the news along, in case others hadn't heard. Thankfully, it ends on a relatively encouraging note, considering the circumstances.

According to Mark Drew, who wrote the entry above, Adobe ColdFusion evangelist Adam Lehman was hit by a car Friday night in London, suffering a broken arm and leg. Mark went with him to the hospital, and reported that he'd had surgery on the arm and was due to have it today for the leg.

Mark added, "Hopefully he will be out in a week or two. Even through this, he has managed to Twitter and update his status. So he is doing OK, if a little out of it due to the pain killers."

That's encouraging news and of course we all wish Adam a speedy recovery.

Adobe announcement: ColdFusion 6, 7, and the end of life of Java 1.4

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Some folks may have missed that Adobe released a technote yesterday that may interest some folks. The good news is that there's no bad news--but you should be aware of the news so that when rumors start running rampant, you'll have information from the source.

Old News, coming to fruition next month: Sun EOL of J2SE 1.4. Adobe's response

Sun has previously announced (in 2006) that J2SE 1.4 (the JVM that happens to underlie CF 6 and 7) would reach end of life in October 2008.

Well that's next month, and Adobe has offered a technote to explain how this affects CFers on 6 and 7 (they don't mention 6, as it's no longer formally supported).

  • Adobe will continue to provide support for configurations requiring this version of the J2SE on a best-effort basis
  • Folks can of course upgrade to CF8, which runs on Java 1.6 (and supports 1.5)
  • FWIW,folks running JRun can also upgrade to later versions of it that support later versions of the J2SE

All that's good news, really, so nothing to get excited about.

Java SE for Business

Sun themselves have also addressed the problem by releasing something called Java SE for Business, which extends the life considerably (up to 15 years), which an organization can license. Adobe has said in the technote that they will be supporting that as well.

So the sky is not falling

All this means that if you hear anyone start some rumor that the EOL of Java 1.4 spells some doom for CF 6 or 7, nip it in the bug. Point them at this technote.

As further testament to why this is not a significant issue, Adobe also makes note there that "Servers running ColdFusion MX 6.x with J2SE 1.3.1 or JRun 4 with J2SE 1.3.1 have historically run without problems long after Sun Microsystems had End of Lifed that J2SE version."

More questions

I imagine some reading this will have questions. I'll say right now that I know nothing more than what I read in the technote. I have no inside information. I just thought we ought to call out the technote so folks knew of it.

But ask your questions, and perhaps another reader (or later, I) will have an answer.

PS I'll grant too that maybe this isn't new information (the Adobe response, and this technote). I only caught it today because I get the feed (as I discussed previously) of new/updated technotes. The technote says it was updated yesterday. They don't say when they're created, so it's possible the technote came out in the past. I just don't recall seeing it. (I wish they would put dates on them for this reason.)

4 New CF Technotes

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I mentioned in a recent entry how you can get a feed of the latest CF technotes and other important Adobe-created CF resources.

If you've not done it yet, let me take a moment to share news of a few that came out on the feed today:

  • Flex Builder 2 RemoteObject calls to ColdFusion 8 CFCs fail - You are unable to connect Adobe Flex Builder 2 RemoteObjects to Adobe ColdFusion 8 CFCs. Flex Builder 2 projects containing RemoteObject calls to ColdFusion 8 fail to connect for the following reasons: You have not entered the proper compiler arguments which point to your ColdFusion 8's services-config.xml and or your ColdFusion server's context root. You have created your Flex Builder 2 project as a "ColdFusion Flash Remot...
  • UtilPagedTempBuffer SqlException error when connecting to MS-SQL (ColdFusion) - When Adobe ColdFusion connects to an MS-SQL database, you may receive the following error: java.sql.SQLException: [Macromedia][SQLServer JDBC Driver]Usage error for UtilPagedTempBuffer: length can not be negative. This issue can occur after you apply a corrupted service pack to SQL. This issue can occur after you apply a corrupted service pack to SQL....
  • Forgotten password and cannot log in to ColdFusion administrator - You have forgotten the Adobe ColdFusion administrator password and cannot log in....
  • Could not find the coldfusion component or interface cfide.adminapi.accessmanager (ColdFusion) - When you install or update Adobe ColdFusion, you receive the following error message: Could not find the ColdFusion component or interface cfide.adminapi.accessmanager. During the installation, you chose to install the CFIDE directory inside an existing CFIDE directory. For example /CFIDE/CFIDE/.During the installation, you chose to install the CFIDE directory inside an existing CFIDE directory. For example...

And since the day I wrote that entry, here are a few others that came out:

  • How to ensure correct UTC Time Conversion for U.S. Daylight Saving Time changes in 2007 (ColdFusion 5) - ColdFusion 5 depends on the operating system to calculate date and time information. The U.S. Daylight Savings Time changes for 2007 will cause incorrect Universal Time Coordinated (UTC) conversions with ColdFusion 5. Note: Support for ColdFusion 5 officially ended on January 1, 2007 -- see www.adobe.com/support...
  • How to import certificates into certificate stores (ColdFusion) - For secure connections to remote servers over SSL, all current versions of ColdFusion require the remote system's SSL certificate to exist in ColdFusion's certificate truststore. This includes any calls from , , , etc. The default truststore is the JRE's cacerts file. This file is typically located in the following places: Server Configuration : cf_root /runt...
  • Solution for Verity Startup Failure with 'DASDOMParser: Fatal ErrorFile' Error (ColdFusion MX and ColdFusion 8) - The ColdFusion Search Server service (Verity) may fail to start with the error: DASDOMParser: Fatal ErrorFile: /{path-to-verity-admin-files}/admin{0-9}.xmlLine: nChar: nMessage: (example: The main XML document cannot be empty) Errors occurred during parsing... This error is generated when trying to start verity from the command line. It may also be found in the {verity-root}/Data/host/log/status.log in the form of: Failed...

I don't think I'll plan to post new entries whenever they come out. Really, one ougjht to just watch the feed for that. This is more a reminder that even in 2 weeks, a good amount of stuff has come out, so you ought to keep en eye on it.

Getting MaxLength Validation to work with CFTEXTAREA Richtext="yes"...busted, but with a workaround

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Have you tried to use the maxlength validation with the new CF8 rich text cftextarea? You'll find that it simply doesn't seem to be working, or works inconsistently. I've done some digging and found why it's not working as it should, and I also offer a workaround for you if interested.

Now, some might point out that with CFFORM maxlength validation, you need to remember to set validate="maxlength", and that's true. And you provide a maxlength attribute and value, as well, but neither of those are what I'm talking about. Nor is it about the fact that you have to account for the underlying HTML that's generated. The validation simply doesn't work as it should, as I'll explain.

The root of the problem

Note that I say it doesn't work as it should--I'm not saying it never works. You can actually get it to trigger a maxlength failure, but it's just not working right.

Here's the deal: what's validated is the length of any data that prepopulates the field, not what the user enters into the field. In other words, it doesn't matter what you (or your user) types into the field. That will not be what's checked, but rather what was there initially. Not too useful (and confusing, for sure).

Let me be more explicit: if there's no text prepulating the field (what's between the CFTEXTAREA) or it's less than the maxlength, then the form submission will always pass without error even if you add lots of text to the field. That's certainly not right.

Conversely, if the field is prepopulated with text that exceeds the maxlength, then the form submission will always fail for the length validation, even if you remove enough text that it should pass. Again, all this could be very confusing if you don't understand what's going wrong.

As an aside, not that it matters to this problem, note that you can also prepopulate a CFTEXTAREA with a Value attribute (not something you can usually do with a normal TEXTAREA.)

A simple sample to test with

Here are 2 examples of what I'm describing. You can drop each into a page (it's a self-posting form, so it doesn't matter what you call the file):

Description (up to 10 characters):
<cftextarea name="description" validate="maxlength" maxlength="10" message="Description must be 10 chars or less" richtext="yes" toolbar="Basic"></cftextarea>
<input type="Submit">

If you run this, you'll notice that it will always pass, regardless of what you enter. Why? Because it's prepopulated with nothing, and that passes the validation, regardless of what you type.

On the other hand, the following will never pass validation, regardless of what you enter, because it's prepopulated with something longer than the maxlength:

Description (up to 10 characters):
<cftextarea name="description" validate="maxlength" maxlength="10" message="Description must be 10 chars or less" richtext="yes" toolbar="Basic">1234567890123</cftextarea>
<input type="Submit">

Obviously, none of this is what you would expect. If you've had people complaining about problems, it's no wonder that you'd be really confused.

(And of course, 10 is too low a number for general use, and unless you're doing an update form you wouldn't likely prepopulate your field as I have, but these make it easy to demo the issue.)

Maxlength validation works fine for CFTEXTAREA, as long as it's not rich text

Now, all that said, things will work just fine if you take out the richtext and toolbar attributes. Go ahead and try it. So clearly it's the richtext feature that's busted with regards to maxlength validation.

Why it's not working

I did some digging into the cfform.js file, which is where the code to do validation lives (in /CFIDE/scripts/) and I found the problem. What's passed to that validation code is not what's typed into the rich textarea (which is itself an iframe buried pretty deep in some code that the FCKEditor builds), but rather what's passed is just the HTML form field value, which in this case will be what was entered into the field when it was initialized (when the page is first loaded).

The ultimate solution is that the CF validation process needs to be changed to instead get the length of whatever was entered into the fckeditor control.

From further digging into that, with regard to some FCKEditor info I found, one might conclude it would be impossible. Many have complained about wanting maxlength validation with the control, and folks working on the tool have said it's a limitation the control.

But here's good news: I did still more digging and learned that the CF javascript API for the new ajax controls does indeed provide access to this information! Woo hoo! You can access it via the ColdFusion.getElementValue('thefieldname') method. With that, one can then test its length.

For now, it's just something you need to do manually. I'll offer some code below that presents how to do this.

Don't forget to account for the generated HTML

Before I show the code, take note about your use of any maxlength test in the richtext textarea (whether it's done by CF itself in the future or by using this manual test): you (and your users, and any messages you give them) need to take into account that the rich textarea will have a length that's longer than just what the user sees/types.

Even with just an "x" entered in a richtext textarea, the underlying content created by the control (and as submitted to the form processing) will be surrounded by paragraph tags:


So that x would then have a length of 8 chars! Just be careful that if you need to tell them they can enter no more than 100 characters, because you're entering the text into a database column of that size, then you need to make it clear that they won't be able to really type 100 characters. And the more formatting they do, the less space they'll have.

In my code below, I offer an option for the validation error message to show them the text as entered, with the html coding.

An example of some code to check the real value entered

So the answer is in using the ColdFusion.getElementValue method, passing it the name of the textarea field to be validated. Using that, and its length property, we can do the needed test. As a quick example, here's a demonstration where the cfform onsubmit method is called to display the real text entered in the field, and its length. Note that I gave the cftextarea a name of "description", and that's what I name in the getElementValue (note that all Javascript is case-sensitive, from method names, to variable names, to names of fields accessed in code):

<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
function testlen(){
   var body = ColdFusion.getElementValue('description');
   alert('text=' + body + '\nlength=' + body.length);

<cfform onsubmit="testlen()">
Description (up to 10 characters):
<cftextarea name="description" richtext="yes" toolbar="Basic"></cftextarea>
<input type="Submit">

With this code, whatever value you enter will be displayed, along with its length.

Now, one may point out that an alternative to using OnSubmit on the CFFORM would be to use OnValidate on the CFTEXTAREA. Well, yes and no. It would normally be a good choice, but we will see later that we will want to create a more flexible form of this code, where we will pass in the name of the field, a test length, and optionally a message to display. The OnValidate only let's you name a method to call, without naming arguments. It's designed to automatically pass in the form field value, just like the built-in validation process, but just as that doesn't work with the rich textarea, so too does it not work for this challenge.

A proposed solution to the textarea richtext validation

So with all that as preface, here then is some code I've put together that may help those wanting to do Rich CFTextArea validation. I've designed it so that you can name the field to validate, the length to test, and optionally an error message to display if it fails the validation, along with an option of whether to show the HTML-formatted generated content in the message.

<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
function testlen(field,maxlen,msg,showval){
   Validates maxlength for a CFFORM CFTEXTAREA richtext field.
   Created by Charlie Arehart, carehart.org, 8/1/2008
   - field (required): name of rich textarea field on form to validate (case sensitive!)
   - maxlen (required): the maximum length to be permitted for the length of the textarea body (including generated html)
   - msg (optional): a message to be shown to the user, or empty string ('') to show a default message defined as "defaultmsg" below
   - showval (option): if 'yes', will show the actual generated body as part of the message

   var body = ColdFusion.getElementValue(field);
   var defaultmsg = 'The ' + field + ' field must be less than ' + maxlen + ' characters.'
   // test textarea body length    if (body.length > maxlen) {
      // if no message is passed in, create a default one (the onsubmit in cfform seems to require all args be passed, so 3rd arg can't be left out, but an be set to '')       if (msg.length < 1) msg=defaultmsg;
      // show the current value, if requested       if (showval == 'yes') msg=(msg + '\nCurrent value (with HTML) is:\n' + body)
      return (false);
//--> </SCRIPT>

<!--- note that for the cfform onsubmit, it appears you must specify all args of a called function --->
<cfform onsubmit="return testlen('description',10,'','yes')" >
Description (up to 10 characters, including HTML):
<cftextarea name="description" richtext="yes" toolbar="Basic">12345</cftextarea>
<input type="Submit">

<cfif cgi.request_method is "post">
   <cfdump var="#form#">

The key is in the call in the onsubmit to the testlen function. The comments explain that it takes the 4 arguments I mentioned. In this case, it's calling testlen('description',10,'','yes'), which is testing the "description" field, for a maxlength of 10, and I'm letting the function create the default error message, while I do want it to show the user the formatted value if they get the validation error. If you want to provide your own message, just provide that in the 3rd argument.

Now, you might think that if you want to skip the 3rd argument but privide the 4th, you could just let it be left unspecified, as in testlen('description',10,,'yes'). But for some reason the OnSubmit attribute of CFFORM doesn't like that. So just specify it as '' if you want to set the 4th arg to 'yes'.

Naturally, if you're happy with the default message and you don't want to show the formatted result to the user, you can then leave off both the last 2 arguments, as in testlen('description',10).

Note as well that you want to call the function (in the OnSubmit attribute) using the form "return testlen(...)", as I have. If you don't, then the form would be submitted anyway even if it fails the validation. By using the return, you cause the result of the function to drive whether the submission takes place, and it returns false if the length test fails.

I could make the function still more robust, testing incoming arguments and such, but it will work for most needs as long as you're careful. Again, remember that when you pass in the name the field, it must be the exact same case and spelling of the CFTEXTAREA name.

That's it. I hope it's helpful. Please let me know what you think in comments, whether it helps or if you see a problem, etc.

Let's hope this is addressed in the CF engine

It would sure be nice to see Adobe get this fixed in the engine. I hope this may help. I'll file a bug report pointing back to this for the details. I've already filed it in the LiveDocs as well.

I will say that if this problem remains into the next release, then the MaxLength attribute and validate="maxlength" option should be removed both flagged as unavailable for CFTEXTAREA when richtext="yes".

More Entries

Copyright ©2020 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting