In code we often need to make use of constant values. It is good practice to use named constants rather than literal values, but what is a good technique for managing constants in an object oriented ColdFusion application?
Update 13 May 2008: This project has been moved over to RIA Forge at http://systemcommand.riaforge.org/
This is an update to a previous entry.
Typically when you want to execute a system command you would use the <cfexecute> tag, but there are some situations when this may not be ideal such as when you want to capture both the "standard output" and "error output" streams of the system command.
You are a person, but clearly you are much more than that. You are good looking and very intelligent and you have a wide range of outstanding skills. You may be great at cooking, an outstanding pianist and perhaps one of the best parents in the world.
However, if I were to interview you for a ColdFusion developer role I would not be very interested in knowing that you make a mean red curry. Although you are a great many things to many people, I would primarily be interested in your skills as a developer. Do you write clean code? Have you used some of the community frameworks? How many years have you been working with ColdFusion? And so on.
In fact my focus would only be on a small part of what you are. I would be focusing on the essential characteristics in you that particularly suited my needs. I would ignore all of the wonderful things about you that are not directly relevant. I have abstracted you into something more generalised and less detailed. You become the abstraction "ColdFusion Developer."
There are various ways to perform pagination in ColdFusion, but I thought I would offer a few additional thoughts to the subject, including an object oriented approach to handling the results.
I have had problems in the past when wanting to use a ColdFusion framework such as Mach II, Model Glue, ColdSpring or Reactor in a shared hosting environment.
For example, suppose you install ColdSpring under the /coldspring directory, then everything works just fine. Then another site on the same shared server also installs coldspring, and then goes on to create a /coldspring ColdFusion mapping to point to their /coldspring directory. Suddenly your site will try to run their copy of the ColdSpring and not yours. Not so good.
It turns out to be quite easy to get around this by simply renaming all of the component references in whatever framework you are using so that the framework is sitting under your own custom directory.
This entry discusses a strategy for handling web forms using object oriented techniques, in particular; how to handle the creation of new data, editing existing data, validating the fields and saving it to a database.
This entry has been updated!
Typically when you want to execute a system command you would use the <cfexecute> tag, but there are some situations when this may not be ideal such as when you want to capture both the "standard output" and "error output" streams of the system command.
Some thoughts on Data Access Objects and Gateways within ColdFusion, and whether or not we really need both of them?
Firstly a quick overview of what these are:
Data Access Object and Gateways are the names given to ColdFusion components that access information from a database or other external data source. Within the ColdFusion community DAOs and Gateways have pretty much taken on the meaning as follows.
With thanks to some smart people on the CFTalk mailing list, here is a concise strategy for getting an automatically generated primary key id after inserting a record into an MSSQL database.
Some thoughts on implementing simple object oriented security in ColdFusion. This entry is a result of great feedback I received from my previous entry.
What primary objects do we need?
There are two main objects that we need - User and SecurityService. There are a couple of other objects that will assist with the security functions and we will discuss them shortly.
The User object
First, we need a User object to represent the person who is logging in. The User object will be stored in the session scope.
The SecurityService object
The Security Service knows how to authenticate a person and create a User. We really only need one copy of the security service object so we will store it in the application scope.
In this example, the security service only has one function, getAuthenticatedUser(username,password), which returns an empty string if the authentication failes, otherwise returns a User object.
