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:
- Can be easily used by those who do not fully understand the software
- Performs the expected operations as planned
- Is efficient
- Is simple
- Is security enabled
- 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:
- 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. - 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/6/08.
Found an issue in our online help system where the content clearly extended far beyond the bottom of the page and yet the vertical scroll bar was missing. The web page with this problem has drag-and-drop capabilities to allow moving elements from one place to another using your mouse. Thus, it contains a lot of CSS, JavaScript, and AJAX code to properly display the drag-and-drop and to save the changes automatically.
I found a <a href="http://www.thescripts.com/forum/thread571528.html" target="_blank">thread post</a> explaining a similar problem and found the following code that "dtc" suggested:
html { overflow: hidden; }
body { height: 100%; width: 100%; overflow: scroll; }
I gave it a shot and it worked. I had to move around some of the elements at the bottom of the page (the copyright) because it was being displayed right in the middle of the content and was just a bunch of gobbly-gook.
I also tried removing some of the CSS to the following:
body {overflow:scroll;}</code>
This was the final fix for both Firefox and IE.
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:
Latest Comments