NOTE: I am in the process of moving my blog to this new system. Thus, it should be noted that this entry was originally posted on 4/1/08.

While developing a web site for a customer, I recently had the problem with evaluating a form field to retrieve that field’s value. For example:

I had a form field as follows:

<input type="text" name="q_1_f35d5381-c9f7-431e-6332-4d404f55ed4c" id="q_1_f35d5381-c9f7-431e-6332-4d404f55ed4c" size="25" value="" />


As you can see I’m using a GUID in the name. This helps me map the form back to another entity after processing.

In order for me to get the value of the field, I loop through the fieldnames and Evaluate() that field as follows:


<cfloop list="#frm.fieldnames#" index="x">
<cfset s.value = Evaluate("frm.#x#") />
</cfloop>


However, when I submit the form and run the code, I received this CF error:


"4d404f55ed4c," on line 1, column 33, is not a valid identifer name.
The CFML compiler was processing: an expression beginning with "frm.q_1_f35d5381", on line 1, column 1.This message is usually caused by a problem in the expressions structure.


It looks like CF attempts to "subtract" the values between the "-" in the GUID. In other words, its attempting to subtract 4d404f55ed4c from 6332 which are the values at the end of my GUID.

After a few hours of attempting to resolve this issue I finally <a href="http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=3&threadid=1350391" target="_blank">posted the issue on the Adobe Forums</a>.

After just a half-hour a kind fellow by the name of Azadi (thanks Azadi, whoever you are) provided a fantastic solution: Array notation on the structure iteself instead of using evaluate! Duh.

I’ve used this solution before but not on a form structure. So, I changed the code that proceses the form as follows:


<cfloop list="#frm.fieldnames#" index="x">
<cfif StructKeyExists(frm,"#x#")>
<cfset s.value = form['#x#'] />
</cfif>
</cfloop>


And it worked beautifully. Remember array notation instead of Evaluate() is a good option in this circumstance.

NOTE: I am in the process of moving my blog to this new system. Thus, it should be noted that this entry was originally posted on 3/21/08.

I consult for a local trucking company on developing ColdFusion reporting tools for an existing management system. Its a unique approach to development because I don’t develop at all, I actually train their network admin to develop web-based applications. Its fun and I enjoy doing it very much.

Recently, we’ve reviewed some essentials to ColdFusion development (and possibly other languages). While its not an exhaustive list of what a programmer should know, I’m highlighting the elements that are somewhat difficult for beginners.

IF/ELSEIF/ELSE statements

Programs make decisions. Plain and simple. The basis for developing a program is so that it can make decisions for us quickly and much faster than mere humans. Albiet, those decisions are at a much lower level (a program usually gives us information so that we can make more informative major decisions) but the program still makes many small decisions based on the information it encounters. As a beginning developer, you must understand how to program those decisions using IF/ELSEIF/ELSE statements.

Components (CF), Classes and/or Objects, and OOP

ColdFusion components mimic objects and classes in other programming languages. They are powerful and provide for easier maintenance and much more modular code (can be ported to other applications). Additionally, using object-oriented code can make team-oriented development much more enjoyable. Also, understanding the fundamentals of methods and functions in components is essential to making those components work.

Frameworks

Frameworks allow faster development and also easier maintenance. Mach-II, Fusebox, and ColdSpring are all ColdFusion frameworks designed to assist ColdFusion developers in creating applications faster. If you can get started using one of these, mroe power to you. But remember, you can always develop your own framework (unless you don’t want to reinvent the wheel).

Enjoy programming! While I tend to ColdFusion, its fun no matter what language you’re using.

NOTE: I am in the process of moving my blog to this new system. Thus, it should be noted that this entry was originally posted on 3/18/08.

One of the most important elements of software (whether desktop or web-based applications) is quality assurance. When we (at DSS) sell a product to a customer, they obviously expect a high degree of quality and usability. Not just for their employees, but also for their citizens. Our products will be used by the public citizens of that state and in a sense our products provide a foundation by which citizens will judge the overall quality and integrity of the state and the services it provides. This is why the quality assurance of our web-based sofware is so important to our customers: they don’t want to betray citizen trust (and to avoid looking like idiots).

The sole focus of quality assurance should NOT be from the programmer or developer perspective (as it was early in my programming career). Q&A is so much more than just making sure the programmer thinks the system works correctly. It is ensuring that additions or modifications to software:

1. Can be easily used by those who do not fully understand the software
2. Performs the expected operations as planned
3. Is efficient
4. Is simple
5. Is security enabled
6. Is future-oriented

I’ll briefly explain each of the items:

1) Can be easily used by those who do not fully understand the software

Because programmers and users are so disparate in their usability logic, a pre-defined "link" must be created for programmers to the user. Some teams create this link by hiring a usability expert or interaction designer. This person is usually solely responsible for creating interfaces for consumers; thus, removing the need for a programmer to include interaction techniques in their development which could save significant time. Interaction designers can also train programmers to instill good interaction design techniques.

This quote perfectly portrays one of the major gaps between usability and software development. Programmers develop logically (that is, in a procedural way) whereas users scan quickly (which tends to be more emotional). These inherent differences always cause confusion for the user and difficulty for the programmer. Thus, when programmers perform the following non-exhaustive list of checks, users will have a much easier time adapting to the new application:

1. Design interfaces first, then build the backend.
   Building functional mockups of systems (or modules of systems) for user testing prior to full development will allow easier and faster modifications to the interface based on user testing results. Waiting until the system is fully coded to perform user testing is much more difficult to modify.
2. Perform user testing with multiple user groups.
   Some users are inherently more skilled at using programs than others. I usually try to get the less-skilled users earlier in user testing, to work out the obvious usability obstacles.

2) Performs the expected operations as planned

This is a no-brainer. If the application does not perform as specified in an evolving requirements document, what’s the use? The application will not do what is expected and should not be built.

3) Is efficient

This is not meant efficiency in programming process (query optimization, efficient array processing, etc.) this is meant to explain efficienies in user interfaces and interface processes. For example, if a user needs to create a question to ask in a survey, have them finish the entire process in one screen. Clearly, adding the question text and adding possible responses (for a multi-choice question) should be done on the same screen. The old screen-refresh-at-submission designs are a thing of past (I admit that I have a lot of work to do). Technologies that assist with this are AJAX and Flex.

4) Is simple

A major application system is simply a lot of smaller components working together. Keeping those smaller components simple will always provide for a stable system.

5) Is security enabled

Don’t plan security into the picture after user testing. Security is an ongoing problem and should be an ongoing concern. Programmers should be routinely and frequently trained in the latest security threats and hacks and those procedures should be implemented DURING DEVELOPMENT; not after it has happened. It is more difficult and more risky to implement security features after development than to implement them during it.

6) Is future-oriented

That’s on odd one, eh? What I mean by "future-oriented" is that programs and applications (whether web-based or not) should evolve. There should be a continual re-evaluation of the application to asess enhancements, modifications and new features THAT MATTER. There is no need developing anything that really won’t matter to users.

In summary, this is simply a short list of a much longer one that may assist with approaching software development properly.

NOTE: I am in the process of moving my blog to this new system. Thus, it should be noted that this entry was originally posted on 2/12/08.

When building ColdFusion code, I like to keep it concise and clean. I like the &lt;!DOCTYPE&gt; declaration at the very TOP of the page. Doing this was easy when we were using Application.cfm: you simply place it on the first line of the page. Our transition from Application.cfm to Application.cfc made me realize that doesn’t work.

First of all, you can’t place the &lt;cfsetting&gt; tag above the &lt;cfcomponent&gt; tag. ColdFusion throws an error thinking your trying to process a &lt;cfif&gt; statement. Thus, I placed it under the &lt;cfcomponent&gt; tag. But there was still one hard return and a tab right before the &lt;!DOCTYPE&gt; declaration. To fix this, just place the &lt;cfsetting> tag RIGHT AFTER the &lt;cfcomponent&gt; tag, on the same line. Now there are no spaces, no hard returns or anything before the &lt;!DOCTYPE&gt; declaration.

Oh, and make sure your &lt;!DOCTYPE&gt; is RIGHT AFTER a &lt;cfoutput&gt; on the same line!

NOTE: I am in the process of moving my blog to this new system. T Thus, it should be noted that this entry was originally posted on 1/7/08.

Recently, we’ve been receiving an error in our production system that I tried to duplicate using my local development server. However, I’m not accessing my development system using SSL like I am with our production system. Thus, to fully duplicate the problem, I had to install a self-signed certificate. Here are the steps I took to install it into my ColdFusion development server:

IMPORTANT: I’m using ColdFusion MX 7 developer with the built in JRun web server.

1) Create a certificate. I used the command line tool for Java called keytool. Got my reference for this from the <a href="http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=UseFlexDataService_09.html">Adobe Web Site</a> and this <a href="http://www.adobe.com/support/coldfusion/using/ssl_with_cf_web_server/ssl_with_cf_web_server03.html">older page</a> from Adobe.

I just open the command prompt and here is a snapshot of my command line entry:

<img src="http://www.chrisschofield.com/cmsblog/client/images/keytoolcmdln.GIF" />

This will save a file called cf.keystore in the current directory, in this case C:\Documents and Settings\Chris Schofield.

2) Now that I’ve got my certificate, I move it to the following directory: [coldfusion install]\runtime\lib where [coldfusion install] is the ColdFusion installation directory on your computer.

3) In a text editor, open the jrun.xml file at [coldfusion install]\runtime\servers\coldfusion\SERVER-INF. Find the following service entry with name="SSLService" and uncomment it.

4) Then I changed the settings (**) as follows:


<!-- Uncomment this service to use SSL with the JRun Web Server
Note that you MUST create your own keystore before using this service-->
<service class="jrun.servlet.http.SSLService" name="SSLService">
<attribute name="port">9100</attribute>

<!-- ** This is the name of the keystore I moved into the CF lib directory. CMS -->
<attribute name="keyStore">{jrun.rootdir}/lib/cf.keystore</attribute>

<!-- ** The password I used to create the directory. CMS -->
<attribute name="keyStorePassword">hi8mtnl0</attribute>

<attribute name="trustStore">{jrun.rootdir}/lib/trustStore</attribute>
<attribute name="socketFactoryName">jrun.servlet.http.JRunSSLServerSocketFactory</attribute>
</service>


5) Restart ColdFusion.

After restarting I can now access the local web site securely by pointing my browser to https://127.0.0.1:9100. Internet Explorer still has a cow about it not being a trusted authority, but heck, I trust myself to not hack my own system so I can safely navigate to this web site. You’d think IE would know when its browsing to the local machine.

Fantastic. I deserve a cookie.

NOTE: I am in the process of moving my blog to this new system. T Thus, it should be noted that this entry was originally posted on 11/27/07.

For the past several days I’ve been troubleshooting a problem with blank fields on our dynamically ColdFusion generated PDF forms. Finally, I found the solution.

Sometimes data used to populate a form field on any of our PDF’s would randomly show up blank when viewing the PDF in Acrobat Reader. It was very random and difficult to track because sometimes the data was there and then on the next PDF build, it was empty. However, it always happened with the same field. Here is a snapshot of the affected fields.

As I modified the other fields on this snapshot, the value of the App_PrimaryName_1 field would appear and disappear. Even moving one of the fields caused the value of App_PrimaryName_1 to disappear. Very frustrating.

Oddly enough, other PDF forms not related to this one had the same problem. The commonality between all of the fields that were missing data on any of the PDF’s was that the fields were always one of the first fields on the first page of the PDF.

The following attempts to remedy the problem didn’t work:

1) Starting with a fresh PDF and add the form fields one-by-one.

2) Changing the field to multi-line, various font sizes including auto, no spell check, read-only, required, etc. Any possible combination.

3) Removing all fields and placing the App_PrimaryName_1 field all by itself on the PDF.

4) Placing the App_PrimaryName_1 field on a different page.

5) Removng all pages except the page containing App_PrimaryName_1.

6) Changing PDF font colors using iText setFieldProperty() method.

7) Changing PDF field margins using iText setExtraMargin() method.

Regenerating the fields using iText regenerateField() method.

9) Various other techniques…

Frustrated and worried that our production date would be pushed back another week, I decided to look at my ColdFusion code that rendered the PDF data. More specifically the query that returns the data from the database. It basically contains two columns: first is the field name and second is the field value.

I noticed that it was returning field names that did not exist in the PDF. However, I still attempted to set the fields even though they were not on the PDF. So, instead of setting all fields sent from the database, I modified the ColdFusion code to verify that the field exists. This should be easy enough using the getFieldType() method in the AcroFields class. However, it seems that Adobe has modified the iText code slightly resulting in several methods being unavailable, including this one. (Adobe uses iText to render HTML pages into PDF using the <cfdocument> tag.)

Thus, I had to improvise:

// Retrieve all of the fields in the form. Luckily, this method was available. It returns a ColdFusion struct.
<cfset pdfFields = pdfForm.getFields()>

// Now begin looping through the struct.

<cfloop collection="#pdfFields#" item="t">

// Then begin looping through the array of values from the database.

<cfloop from="1" to="#ArrayLen(aryValues)#" index="k">

// If the field name exists, set the field value and then delete that entry from the array for faster processing on the next iteration.

<cfif Compare(aryValues[k].name,t) EQ 0>
<cfset pdfForm.setField(Trim(aryValues[k].name), aryValues[k].value)>
<cfset ArrayDeleteAt(aryValues,k)>
<cfbreak>
</cfif>
</cfloop>
</cfloop>

After several attempts, the code change worked! It now correctly rendered all appropriate fields on the PDF form.

Thus, there seems to be either a bug in iText that causes the missing data when you attempt to set the value of a field that doesn’t exist. This fix is a bit bulky compared to the original code, but cleaner in that I’m setting only fields that exist. Even with the extra processing overhead, it is actually faster at rendering the PDF’s than the previous code. Probably because its only setting data on existing fields.

I think I’ll have a Kit Kat.

NOTE: I am in the process of moving my blog to this new system. Thus, it should be noted that this entry was originally posted on 11/26/07.

For several years our products have populated PDF forms with data from a database. This has worked very well with our implementation of a modified cfpdfform custom tag similar to Ben Forta’s.

However, one problem that we could not solve was the need to flatten the PDF forms after they’ve been populated. Essentially, we needed to remove the fields but leave the values in the same place. This was not possible with the cfpdfform. This is possible with CF8, but I’m not going to tell my customers to run out and purchase CF8. Especially when some of them have Enterprise licenses.

Anyway, I found iText. An open source Java library specifically designed to manipulate PDF’s. It’s fantastic. It should be noted that the iText library is found in the CF7 lib directory! Which makes it easy to incorporate into your CF project. How interesting of Adobe (or was it Macromedia at the time?) to use the iText library instead of one of their own?

Well, I replaced the 500 lines of code in our cfpdfform tags with about 30 lines of code using iText. Its much more efficient and, for the most part, is very reliable. Here is a sample of the code we used:


//define path and file name of the PDF template with form
pdfFile=arguments.PDFTemplate;

//define the name of my output file

newFile=arguments.PDFOutput;

//create the output file

fileIO=createObject("java","java.io.FileOutputStream").init(newFile);

//load the template PDF with the iText PDF reader

reader = createObject("java","com.lowagie.text.pdf.PdfReader").init(pdfFile);

//load the template into the iText PDF stamper and specify the output file

pdfStamper = createObject("java","com.lowagie.text.pdf.PdfStamper").init(reader, fileIO);

//create a form object to reference

pdfForm = pdfStamper.getAcroFields();

//set the form fields

for (i = 1; i LT ArrayLen(aryValues); i = i + 1){
pdfForm.setField(Trim(aryValues[i].name),aryValues[i].value);
}

// Flatten the form to remove text fields and replace with existing data.

pdfStamper.setFormFlattening(true);

// Close stamper.

pdfStamper.close();


I’m a big fan of iText. So much so that I purchased the book “iText In Action.” It has been an invaluable resource for our dynamic PDF generation.

Tomorrow I’ll be presenting to the Northern Utah ColdFusion User Group (NUCFUG) on Framework One. This awesome open-source ColdFusion framework is the result of an idea by Sean Corfield and created by him and a few ColdFusion gurus.

Framework One is hosted on GitHub.

There is also a Google Groups forum.

If you haven’t taken the chance to work with Framework One, I highly recommend you do. It’s simplicity is extraordinary.

It’s great because the entire framework is built in one CFC, has a comprehensive API and it’s super simple to implement.

NOTE: I am in the process of moving my blog to this new system. Thus, it should be noted that this entry was originally posted on 6/6/08.

I’ll admit that I sometimes use hidden form fields in my web applications. I cringe every time I do, but I do it anyway. They’re convenient and make it easy to track some elements in a web application.

The problem with hidden form fields is that users can manipulate them. This is done by simply saving the web page to disk, modifying the code, then opening the page on disk in a web browser and submitting the form. This is dangerous and can cause severe problems. Hence, securing forms is essential. This is how I do it:

ColdFusion has two utilities that are available to obfuscate code. This is useful when you don’t want users to see or modify your plain text CFML code. However, there are some drawbacks to both utilities…