Rob's Ramblings

A longstanding issue with CFSELECT still exists in CF9. For as long as CF has had CFFORM, there has been a bug in validating CFSELECT fields for required selections. It only looked to see if you had an option selected, but never checked to make sure that you had a value selected. So often we create a first option in a select box that has no value as a placeholder. According to CF, that's good enough to pass the required check if you just selected the placeholder. Adobe has been pinged on this issue by many developers over the years and still has failed to fix this for some reason.

There is a workaround for this though. When you use the required and validateat attributes of a CFINPUT, CFSELECT, or CFTEXTAREA, it pulls the front-end validation from CFIDE/scripts/cfform.js by default. Since this contains the incorrect method, you can do one of two things. You can edit the CFIDE/scripts/cfform.js file annd make the fix (it's extremely simple), or you can make a copy of that file, save it elsewhere, and access the file via the scriptsrc attribute of CFFORM.

The original fix for CF7 and CF8 can be found here: http://www.beetrootstreet.com/blog/index.cfm/2007/1/8/CFFORM-doesnt-catch-unselected-dropdown-lists-when-requiredtrue

The fix for CF9 is similar, you just need to make the following fix.

From:

if(_c=="SELECT"){
for(i=0;i<_b.length;i++){
if(_b.options[i].selected){
return true;
}

to:

if(_c=="SELECT"){
for(i=0;i<_b.length;i++){
if(_b.options[i].selected && _b.options[i].value !=''){
return true;
}

Comments are moderated solely for spam purposes.

This is a followup to my previous post on this topic, and a solution found.

Thanks to comments here and from House of Fusion, I learned that Verity does not work on Macintosh OS X. An alternate solution must be found. Thanks in part to Dave Watts of Figleaf, I found it.

Setting Up Verity

From Dave's suggestion, I installed CF9 on an OS that has Verity - Windows in my case.I have an instance of WinXP SP3 running via VMware Fusion. I have the network adapter set up for NAT, so it gets it's own internal IP address.

I installed it as a standalone edition with the local web server on port 8500. After installation I ran the web-based config to get it all up and running. At that point, I disabled all the CF services except for the ColdFusion Search Services, which is set to Automatic. I went into Windows Firewall and opened up the three ports Verity uses.

I went back into my OS X CF admin, and changed the Verity K2 host to the IP address of my Windows instance. Tried to connect to the service and.... nothing. At this point it was 1700 on Friday so I shut down and took the weekend off from this.

I returned to this task this morning with a fresh head, and found some documentation on CF's instance of Verity. It only allows connections from one machine, and by default it is set up to be 127.0.0.1. A search found this address in two XML files in my C:\ColdFusion9\verity\Data\host directory, as well as the C:\ColdFusion9\verity\verity-install.cfg file. I went into all three files, and changed the IP address and mask from 127.0.0.1 and 255.255.255.255 to my OS X internal IP address and a mask of 255.255.255.0. I restarted the ColdFusion Search service on Windows. I cannot tell you for certain which change was the difference maker, but when I refreshed the ColdFusion Collections link on my OS X CF9 admin server, it was connected to the Windows verity!

Fun with soft links

The next task was to set up the collection that I was going to use. The function to do the indexing is set up to create the collection first if it does not exist.

As a reminder, my QA and production environment are Unix boxes, which does have Verity support from CF. On it, CF is set up in the /opt/coldfusion directory. Therefore the verity collections are in /opt/coldfusion/verity/collections/. I have been very strict in making sure that my local development environment on OS X mimics the directory structures used on QA and production, using soft links where needed. So on OS X, I created /opt, and inside /opt created a soft link for "coldfusion" to link to my /Applications/ColdFusion9/ directory.

The path to the verity folder is /opt/coldfusion/verity/collections/. My first instict was that CF would create the directories as needed. I ran my indexing template, and got back the following:

The collection was reindexed. 0 records have been inserted. 0 records have been updated.

Not what I was expecting. I looked in my /Applications/ColdFusion9 directory, and saw no new "verity" directory created. So where was it? I looked on my WinXP instance in C:\ColdFusion9\verity\collections, and saw no new collections created there. I was stumped until I looked at the C:\ drive, and found an "opt" directory there. Expanding it, I found C:\opt\coldfusion\verity\collections\ and my collection inside there!

Now knowing what had happened, I needed to link OS X to that verity folder. I shared the C:\opt\coldfusion\verity folder on Windows, and mounted it in OS X. I then went into /Applications/ColdFusion9, and made a soft link to the mount point for the verity shared folder at /Volumes/verity. So now /opt/coldfusion/verity links properly to the C:\opt\coldfusion\verity on Windows. I think I've got it all, so I run the index again.

The collection was reindexed. 0 records have been inserted. 0 records have been updated.

Huh?

The Final Hurdle - proper location of the documents

Looking in the CF9 admin, I read this:

Because you have a remote K2 server configured, you must ensure that the documents to be indexed are accessible from the ColdFusion server machine as well as the computer on which the K2 search services run.

And that's when I realized that the documents to be indexed couldn't be on OS X, they had to be on windows. I created an uploads directory on Windows, and shared it. I mounted the share on OS X. Then, again mimicing our QA and production structure, I soft linked the root uploads directory to the mount point (/Volumes/uploads).

A final running of the indexing returned this:

The collection was reindexed. 106 records have been inserted. 0 records have been updated.

Wahoo! And a test of the search returned results as expected!

Comments are moderated solely for spam-prevention purposes only.

A legacy application I maintain uses Verity, and is being moved from a CF7 server to CF9. We do not have the approval to upgrade it to use Solr at this time.

My development environent is Snow Leopard. I have CF9 Developer Edition installed clean on it. The installation never gave me options for setting up Verity. So imagine my surprise when I find that Verity is not installed in my CF9.

After asking around some, I did some digging myself. I think there might be an issue with the OS X installer that could explain this.

I opened the Adobe_ColdFusion_9_InstallLog.log file, and searched for verity. I found this line:

"Install File:             /Applications/ColdFusion9/WEB-INF/cfusion/lib/verity.jar"

Looking in my /Applications/ColdFusion9/ directory, there is no WEB-INF/cfusion/lib directory. I found the verity.jar file in /Applications/ColdFusion9/lib/.

So putting this together, it looks like the installer is looking in the wrong place for this?

This brings me to two questions:

1. How do I report this to Adobe?
2. Can I manually install this verity.jar file? I have no experience in that arena, would need to be handheld through it.

Any help is appreciated.

Comments are moderated solely for spam-prevention purposes only.

Adobe released CFBuilder to the paying public, as we all know. And it looks like they fixed quite a few things from the last beta. But they also broke one thing, and it's a real bother.

As of this official release, you no longer can manually install CVS into a standalone installation of CFBuilder. In teh betas, you could do this via the Eclipse 3.4 update sites (noted in this blog post). Now, it generates an incompatability error.

UPDATE: The fix to this was to use the correct update site for Eclipse 3.5. The site to use is http://download.eclipse.org/releases/galileo/. I had been using http://download.eclipse.org/eclipse/updates/3.5 and that was incorrect. Thanks to Nathan Mische for pointing this out to me!

Comments are moderated for this blog solely for spam-prevention purposes.

This post is one of those where I am hoping somebody can provide me with some assistance.

I have been using CFBuilder on Snow Leopard for months now. I love it. I especially love the server consoles, the tailview, and the RDS services. The only thing I have not loved about it are the occasional crashes, but I expect it from beta software.

In the last week however, they have become more than occasional. They have become regular. CFBuilder constantly is hanging, eating up all of my CPU, and giving me constant Java Heap Space errors. Ususally it's trying to build project settings or index projects, and I can let them go on for literally hours at a time and nothing will happen. I've had to Force Quit CFBuilder numerous times now.

I went so far as to uninstall it and do a fresh install, no avail.

If anyone has some things that could help me, I would be appreciative. I'm back using CFEclipse, and it's just not the same for me.

Please note that all comments are moderated for spam-prevention purposes only.