Tea Boy

2003-05-01T00:17:00.000-07:00

kwfu: ['relocated']

I've moved!

I've finally got round to setting up my blog on a CF server.

The new url is http://www.spike.org.uk/fu/blog.cfm

I'll be gradually moving the content from here to the new site, so update your bookmarks Nachos!

Spike

2003-04-10T07:19:00.000-07:00

kwfu: ['farcry','cms']

Just finished a couple of hectic days working on the next release of FarCry. If you don't know what FarCry is, I suggest you get on down to the website and have a look at it.

http://farcry.daemon.com.au

It's a complete enterprise content management system built in CFMX built by the guys at Daemon in Sydney Australia. It supports many of the things that were available in Spectra, but it's FREE!!!

100% Open source goodness!

You can go download it from here, or you can go and look at the demo site here. If you do go to the demo site, make sure you login and check out the admin interface. That's the same interface you get from a fresh install.

If you're currently running Spectra and are looking for something to migrate to, I'd definitely suggest you download it and take a look. It's already been used to migrate a few sites in Australia. They aren't small sites either. Roche Pharmaceuticals Asia Pacific intranet and Integral Energy

It's currently being labelled as version 1, but a lot of the code's been in use for the last 4 years in various different projects.

Definitely worth a look

Spike

2003-02-26T18:14:00.000-08:00

kwfu: ['cfproperty','cfc']

A long time ago I promised to put some more info in my blog about CFCs. Well, now I'm coming good on that promise.

You may be wondering exactly what use the <cfproperty> tag is. Well, there are at least 2 uses for it. I was intending to put them both into this post, but I got a bit overexuberant with the examples, so I'll split it into 2 blog posts.

1. Providing static data for component instances

When you create a component instance, you can use the getMetaData() function to retrieve all the data that is defined in the <cfproperty> tag. You also get information about the attributes in the <cfcomponent> and <cffunction> tags, but I digress. As an example:

Say you have employee.cfc that contains employee information.

<cfcomponent displayname="employee">
<cfproperty name="minage" type="numeric" value="18">
<cfproperty name="maxage" type="numeric" value="65">

<cffunction name="getEmployee" access="public">

</cffunction>



</cfcomponent>

You can create an instance of this component as follows:

<cfscript>
emp = createObject('component','employee');
</cfscript>

You can then retrieve and view the data defined in the cfproperty tags like this:

<cfdump var="#getMetaData(emp)#">

If you look at the output from the <cfdump> tag, you will notice that it contains all the attributes of all the <cfcomponent>, ;<cfproperty> and <cffunction> tags in the component. This is true even if you define your own attributes in those tags. This can be particularly useful for defining information about how component instances and properties of those instances should be treated. You could, for example, create an editHandler attribute for the <cfcomponent> tag that defined what file should be used to edit instances of that component. You might also use this to determine default values for the properties of your component instance. The <cfproperty> tag will not create the properties for you, but you can use the metadata to initialize them yourself.

Something like this:

<cfcomponent displayname="employee">
<cfproperty name="minage" type="numeric" value="18">
<cfproperty name="maxage" type="numeric" value="65">

<cfscript>
init();
</cfscript>

<cffunction name="init" access="private">
<cfset md = getMetaData(this)>
<cfloop from="1" to="#arrayLen(md.properties)#" index="i">
<cfset this[md.properties[i].name] = md.properties[i].value>
</cfloop>
</cffunction>



</cfcomponent>

The following code will allow you to see how this works:

<cfscript>
emp = createObject('component','employee');
</cfscript>
<cfdump var="#emp#">

This is a pretty useful feature, but you need to be careful about the time that getMetaData() can take to return data in complex component hierarchies. You should also be aware that you could quite easily do this instead:

<cfcomponent displayname="employee">

<cfscript>
init();
</cfscript>

<cffunction name="init" access="private">
<cfset md = getMetaData(this)>
<cfset this.minage = 18>
<cfset this.maxage = 65>
</cffunction>



</cfcomponent>

The downside of this way of doing things is that when you use the component browser you will not see what the default values will be in the documentation code.

Hopefully all that made sense, next time <cfproperty> and webservices.

Spike

2003-02-23T16:58:00.000-08:00

kwfu: ['travelling']

Well, it's been a long time since my last post and a lot of things have happened in that time...

I've left my job in the Netherlands, been ski-ing in the French Alps for Christmas and New Year, spent a few weeks travelling across Canada, and got to Australia in time to speak at MXDU in Sydney on 19th and 20th of February. The conference was great and many thanks go out to the speakers and organizers who made it as good as it was. Special thanks to Geoff Bowers and the team from Daemon who had all the speakers over for a good ole aussie barbie on Friday night.

I'm planning on hanging around in Australia for a few months before moving on to Asia for a while. After that, who knows, but it might well involve getting in touch with the Australian authorities for a slightly more permanent visa.

Spike

2002-11-01T03:45:00.000-08:00

kwfu: ['english','OT']
I got this in an email from an old college friend of mine today:

*snip*
We have a logo that says "Research And Development", but the boss wanted to put a hyphen between the words Research and And and And and Development in my Research-And-Development logo.

I said that the sentence 'I want to put a hyphen between the words Research and And and And and Development in my Research-And-Development logo' would have been clearer if quotation marks had been placed before Research, and between Research and and, and and and And, and And and and, and and and And, and And and and, and and and Development, as well as after Development!
*snip*

Good old english

Spike

2002-10-17T09:34:00.000-07:00

kwfu: ['UI','architecture','slashdot']

An interesting thread about UI architecture popped up on slashdot today. Qute a few of the responses don't answer the question, but a lot of them should be interesting to people building complex systems with CFMX and Flash.

Spike

2002-10-16T05:43:00.000-07:00

kwfu: ['CF','Link','advanced']
Stumbled across this page on the Macromedia website today. Very useful set of articles on Advanced ColdFusion development all in the same place.

Spike

2002-10-16T01:10:00.000-07:00

kwfu: ['super','cfc','extends']

Continuing the cfc theme of the last couple of weeks, here's a little trick that might be useful to some people.

Suppose we have a cfc called base.cfc that has a method called init(). The purpose of init() is to set up some initial data and parameters for the component. The use of init() to initialize an object is common in the Java world, so it makes some sort of sense to follow the same idea in components.

Now, suppose we have a cfc called extends.cfc that extends base.cfc. Extends.cfc also has a method called init() to initialize it's data. This could cause a problem because extends.init() will override the init() function declared in base.cfc. In the Java world, we would use the super keyword to access the init() method in the parent component. Unfortunately the super keyword doesn't work with components so there isn't an easy way to call a method that has been overridden by an extending component.

The little trick that I'm about to show you relies on the fact that you can attach methods to a component after it has been instantiated. If the data in the un-named scope is put into a structure, you can easily access all the data in that structure as long as you know what it is called. For the purposes of this example I'm going to use 'protected' as the name of my structure.

Take the following code:

base.cfc
<cfcomponent hint="base component">

<cffunction name="init">

<cfset protected = structNew()>

<cfset protected.a = "value of a">
<cfset protected.b = "value of b">
</cffunction>

</cfcomponent>

Extends.cfc
<cfcomponent hint="extending component" extends="base">


<cffunction name="getProtected" access="private">
<cfif isDefined('protected')>
<cfreturn protected>
</cfif>
</cffunction>

<cffunction name="init">

<cfset protected = structNew()>


<cfset super = createObject('component','base')>


<cfset super.getProtected = getProtected>


<cfset super.init()>


<cfset super.protected = super.getProtected()>


<cfset structAppend(protected,super.protected,false)>


<cfset protected.c = "value of c">
<cfset protected.d = "value of d">
</cffunction>


<cffunction name="getAll">
<cfreturn protected>
</cffunction>

</cfcomponent>

invoke.cfm
<cfset obj = createObject('component','extends')>
<cfset obj.init()>
<cfdump var="#obj.getAll()#">

Now we've managed to create the functionality of a super.init() in a CFC.

The caveat to this is that we're not really duplicating what you get with the super keyword in Java. The important difference is that in Java we wouldn't be creating a separate object instance to access the method declared in the parent, the method would be running from within the context of the extending component. This is important if the method relies in any way on the data that exists in the instance.

For example:

You have a generic shopping cart component called cart.cfc that has a method called sum() that calculates the total cost for the items in a cart. Say bargain.cfc extends cart.cfc and has a method called sum() that calls the sum() method in the cart.cfc, then applies a discount of x% to the result. If the cart items are stored in the un-named scope of bargain.cfc, the sum() method in cart.cfc will not have access to them, and so will most likely return ZERO as the total cost for the items in the cart!

Clearly this is not desireable, so although we can get some of the way to emulating super in Java, it doesn't get us all the way there.

Spike

2002-10-14T09:35:00.000-07:00

kwfu: ['cfc']
A little update to the 'this' vs 'un-named' scope discussion from last week.

Sean Corfield posted this nice little snippet on a mailing list:

test.cfc:
<cfcomponent>
<cfset bar = 42/>
</cfcomponent>

invoke.cfm:
<cfscript>
function foo() {
return bar; // not this.bar!
}
// create an instance of the component
x = createObject("component","test");
// attach the function to the component
x.abc = foo;
// Create a variable to hold the return value of the attached method
y = x.abc();
</cfscript>
<--- Output the results --->
<cfoutput>
<cfdump label="x" var="#x#"/>
y = x.abc() returned #y#
</cfoutput>

"You can add UDFs to component instances and manipulate them
however you want. Because CFMX resolves names at runtime - late binding
- not at compile time, you can add code after the component has been
written that does 'Bad Things(tm)' with the component...

This is true of any language that does dynamic binding of variables
(until the compiler is specified to add binding restrictions at
compile-time)."

It turns out that not only can you attach a method to a component to access the variables in the un-named scope. You can also call methods with an access attribute of private...

test.cfc
<cfcomponent>
<cfset bar = 42/>
<--- Create a function that is private --- >
<cffunction name="hideme" access="private">
<cfreturn "You're kidding, right?">
</cffunction>
</cfcomponent>

invoke.cfm
<cfscript>

function foo() {
return bar; // not this.bar!
}
// Create a function that calls the hideme() method.
function bar() {
return hideme();
}

x = createObject("component","test");
// Attach the method to return a hidden property
x.abc = foo;
// Attach the method to call a hidden function
x.def = bar;
// Call the functions we just attached and set variables equal to their return values.
y = x.abc();
z = x.def();

</cfscript>

<cfdump label="x" var="#x#"/>

<cfoutput>
y = x.abc() returned #y#<br>
z = x.def() returned #z#<br>
</cfoutput>

Interesting stuff.

Spike

2002-10-10T13:12:00.000-07:00

kwfu: ['cfc']
There's been a lot of talk about CFCs recently, and I thought I'd put a few of my ideas and opinions up here.

The first topic that seems to have been getting quite a bit of discussion is the use (or not) of the 'this' scope.

For those of you not familiar with CFCs, the 'this' scope allows you to set a variable from within your component and have it available outside the component.

e.g.

test.cfc
<cfcomponent hint="simple test">
<cfset this.foo = "bar">
</cfcomponent>

invoke.cfm
<cfscript>
obj = createObject('component','test');
</cfscript>

<cfoutput>#obj.foo#</cfoutput>

An alternative to this is to create a method that will allow you to update the value stored in a property. This might be useful in a situation where you have a product component that requires that the price is always an integer value.

e.g.

product.cfc
<cfcomponent hint="simple product component">
<cfset this.name = "">
<cfset this.Description = "">
<cfset this.price = -1>

<cffunction name="setPrice">
<cfargument name="newprice" type="numeric" required="yes">
<cfif int(arguments.newprice) NEQ arguments.newprice>
<cfthrow message="Prices must alwasy be integer values">
<cfelse>
<cfset this.price = arguments.newprice>
</cfif>
</cffunction>
</cfcomponent>

updateprice.cfm
<cfscript>
obj = createObject('component','product');
obj.setPrice(10);
</cfscript>

This works just fine as long as you have control over all the code that is interacting with your component, but it is all too easy for someone to write code like this:

updateprice.cfm
<cfscript>
obj = createObject('component','product');
obj.price = '$10';
</cfscript>

You don't have any way to stop this from happening...

Enter the un-named scope in components.

When you create an un-scoped variable in a component it is created in an un-named scope that is only available to the component and any components that extend it. The fact that components that extend it have access is counter to what the documentation says, and it has been entered as a bug #48483, but that's the way it works at the minute.

e.g.
test.cfc
<cfcomponent hint="simple test component">
<cfset foo = "bar">
</cfcomponent>

invoke.cfm
<cfscript>
obj = createObject('component','test');
</cfscript>
<cfoutput>#obj.foo#</cfoutput>

The code above should throw an error because the variable foo is created in the un-named scope.

If we want to be able to read and write the foo variable in the component we would need to do something like this:

test.cfc
<cfcomponent hint="simple test component">

<cfset foo = "">


<cffunction name="getFoo">
<cfreturn foo>
</cffunction>


<cffunction name="setFoo">
<cfargument name="newval" type="string" required="yes">
<cfset foo = arguments.newval>
</cffunction>

</cfcomponent>

invoke.cfm
<cfscript>
obj = createObject('component','test');
obj.setFoo('bar');
</cfscript>

<cfoutput>#obj.getFoo()#</cfoutput>

The big advantage of this approach is that you have absolute control of the data from within the component itself. This idea is commonly known as encapsulation and is very important when building complex systems. The reason it is important is that you only have to look inside the component itself to see all the possible ways it's data can be changed.

The downside of using this system is that you have to write a lot more code to create all your get and set functions, and you are likely to have to think carefully about what those functions will be.

e.g.

Suppose you have a much more complex product component that has 50 properties stored in the un-named scope. You probably don't want to have to write 50 get methods to retrieve all the properties out of it, and you probably don't want to put 50 set method calls when you want to update the product, or create a new one. You are most likely going to create methods that will update or retrieve multiple properties at once. You might start with getAll(), getDetails(), and getSummary(). Later you find out that someone needs a specific set of properties for some other reason, and later still a few more methods get added for other groups of properties. Before you know where you are you have a big mess in your component that is very hard to maintain.

You can offset the potential for these problems if you set out from the beginning to plan the application in the same way as many people have been doing for years in the Object Oriented world. There are lots of other places where you can get good information about how to go about planning, so I won't go into it here.

By now, you may well be wondering why you would ever want to put anything into the 'this' scope, because all I've done is tell you that it's a bad thing.

Lets look at another example:

test.cfc
<cfcomponent hint="simple test component">

<cfset foo = "">


<cffunction name="getFoo">
<cfreturn foo>
</cffunction>


<cffunction name="setFoo">
<cfargument name="foo" type="string" required="yes">
<cfset foo = arguments.foo>
</cffunction>

</cfcomponent>

invoke.cfm
<cfscript>
obj = createObject('component','test');
obj.setFoo('bar');
</cfscript>

<cfoutput>#obj.getFoo()#</cfoutput>

This time, the name of the argument passed to setFoo() is the same as the name of the variable it is setting in the un-named scope. Unfortunately, it doesn't work. No matter how you try to set the variable in setFoo(), getFoo() will always return an empty string. I'm not too sure what's going on to stop the variable assignment from working as expected. It could be that because there is a variable in the 'arguments' scope one is automatically created in the local scope for the function. It could be one of a number of things, but the bottom line is that you won't get an error, and you won't get the variable being set. This is one of the nastiest types of problem. A bug could go months without being discovered, then like a rake in the grass it hits you in the face when you least expect it.

There are a couple of ways to get around this:

The first is to make sure that the variable you are assigning never has the same name as the argument you are using to assign it. This works, but is a bit difficult to maintain and just doesn't seem so elegant as the other option.

The second is to create a pseudo scope as a structure and put all of the properties into this instead. You might call this pseudo scope 'private', 'protected', 'Instance' or even 'variables' since that doesn't seem to exist inside a cfc. Personally I prefer to use 'protected' as that's what I think it maps to best when comparing to other languages.

There are some other interesting things when using components as webservices, but I think I've given you enough to chew on for one blog entry.

Spike

2002-06-24T12:44:00.000-07:00

kwfu: ['cfupdate','cfinsert','session','application','cfform','cfinput']

Someone sent me an email today asking what I think is so wrong with cfinput, cfform, cfinsert, cfupdate and session variables.

Fortunately (or unfortunately depending on your point of view) for them I was in a typing mood. This was my reply:

The main reason for listing those tags is that they put restrictions on the flexibility of what you can do, and they make future maintainability/modification more difficult.

Take CFFORM for example. Although it allows you to add some validation to the cfinput tags that are contained within it, there are several limitations to this. Some examples:

There isn't an easy way to have the validation fired when the focus moves from one of the form fields.
If you are running a version of CF Server earlier than CF 5, you can't use a regular expression to validate the content of a form field.
Although you can specify a Javascript function to fire when validation fails, this sort of defeats the purpose of using cfform in the first place.
Customizing the behaviour of the validation is relatively difficult, and if you do change the validation scripts in the cfusion directory, the changes will also have to be applied to all servers where the application is deployed.
The cfform tag does not permit a method of get. Only post operations are allowed.

Admittedly, none of the above problems are insurmountable if you really insisted on using cfform, but I have found that in general it is easier to read and maintain systems that have been written using standard HTML tags.

In addition to this, the forms generated with cfform can only be used in ColdFusion applications, but the ones which use HTML only can be used in conjunction with any server side technology. I am a strong believer in solving problems properly once, and re-implementing the same solution many times.

The database tags - cfinput and cfupdate, suffer from pretty much the same sort of problem. Although they do a good job of putting data in a database, they are not so nice 6 months down the line for someone who has to maintain the application. i.e. You can't just look at an action page that uses cfinsert and cfupdate and see what is happening. You will have to look at the form from that is posted to the action page, and almost certainly the database itself. Also, if you make a change to a database table, or split a single table into two tables, you have to go with the native SQL anyhow. If you're going to need to use SQL statements in your application then you might as well be consistent and use them throughout.

In essence the problems with these tags are not so much in the functionality that they offer, but in the difficulty of maintaining the applications that use them long after their original purpose has been forgotten.

Session variables I avoid for 3 reasons.

1. It is not possible to get full information about all the sessions that are active on a particular server at any given time. Such information as how many active sessions there are, when the sessions were last accessed, the usernames of the users who have active sessions etc.

This sort of information often is not required in the initial application stages, but often it does become a requirement in the application at some point down the line.

2. Locking. I don't think I have ever seen an application that was completely free of errors with regard to locking access to session (or application) scoped variables. Even turning on the full checking option in the ColdFusion Administrator doesn't catch all the problems. Consider the following code:




<cflock scope="session" type="exclusive" timeout="2">
<cfset request.userprofile = session.userprofile>
</cflock>

OOPS!!!

All we have done here is make a reference to the variable in the session scope.

Under heavy load, the following code will almost certainly cause the server to crash due to memory corruption in the session scope.



<cfset request.userprofile.counter = request.userprofile.counter + 1>

What we should have done in the first block of code is use the duplicate() function to copy the data from the session scope:

<cflock scope="session" type="exclusive" timeout="2">
<cfset request.userprofile = duplicate(session.userprofile)>
</cflock>

The third reason for not using session scopes is to avoid any problems in the future if the application becomes too busy to run on a single server. Once that happens, you have to make sure that users stay on the same server for the duration of their session, as sessions are not shared between servers. This has changed in CFMX where it is possible to share sessions across clustered servers, but for earlier versions of CF it is a bit of a problem.

In answer to your question about the checklist, I did have a checklist, but it wasn't on a piece of paper. It was a mental checklist of things to look out for.

It is actually more like a set of guidelines than a checklist. It goes something like this:

1.
If a tag like cfform,cfinput,cfselect,cftable is used, is there an overridingly good reason for using it over manually doing the same thing with coldfusion code. In other words, if a tag has been used that encapsulates some programmatic logic, that could otherwise have been written using ColdFusion code is there a good reason for doing so.

The reasons that I feel these tags need to be justified is that they are not so readable when it comes to looking at your own, or anyone elses code in 6 months time, and that they are less flexible should the application need to be changed at a later date.

Having said that, I won't necessarily always decide that the use is not justified, I'd say it's something like 70-80% of the time.

2.
If data has been put into a persistent scope such as session, server, or application, is there a good justification for doing this over putting it in a database, or using the request scope. The main reason for doing this is that the persistent scopes all need to be locked, and as the code example above shows, it can be very difficult to track down problems with locking. The second reason for doing it is that if the application ever needs to run in a clustered environment there may be problems as mentioned above.

3.
If there are calls to tags which reach out from the ColdFusion server to some other system, could those calls become hung threads waiting for a response, or could they cause locking issues. The sort of tags I am thinking of here are cfhttp, cfmail, cfpop, cffile, cfdirectory, cfftp, cfldap, cfsearch, cfcollection, cfobject etc. All these tags can communicate with processes outside the control of the ColdFusion server, and the coldfusion developer. Some of them need to be locked and some of them can cause hung processes which are waiting for a response from the external system. Exactly what can be done with this sort of code is very dependent on the scenario, but it is something I will be looking for as a potential area of problems.

4.
If custom tags are used, are there a lot of nested recursive calls. This can slow down an application to an incredible degree. I have seen coldfusion applications that were built by very competent Java developers. The problem is that ColdFusion has a 'speed bump' of a few milliseconds each time it has to call a custom tag. Multiply that few milliseconds by a factor of several hundred or even a few thousand and you have an application that may not be particularly complex running at a crawl.

5.
Databases and queries. Often applications performance can be improved from several seconds per page request to several tens of milliseconds per page request just by adding a database index in the right table, or by creating a lookup table for id values. Depending on the nature of the application, it may or may not be possible to make changes to the database structure, but it is usually possible to add a few indices to the tables that are regularly queried.

6.
Consistency in naming of variables, naming of files, and structure of the file system. This is so incredibly important for the maintainability of an application that it really should be one of the primary design considerations for all applications. Unfortunately, short of rewriting the entire application there isn't much you can do to change it once an application has been written. The main reason I check this is so I will know for future reference whether or not I should accept any contracts to make changes to the application. It is also useful information for the client for maintaining the application, or for developing new ones.

There are probably some more things that I'd check, but I think that's enough for you to chew on for now. If you've got this far without looking up award yourself top marks for powers of concentration ;-)

NOTE: Ben Forta sent me a mail pointing out that although these are all valid points you should not forget that the majority of CF applications are not mission critical, they are more like reporting or data entry apps. In these cases it often makes a lot of sense to use all the things I have discouraged above.

I should have made it clearer that the mail to which I was responding was asking about a checklist I mentioned that I use when travelling around providing ColdFusion consulting. Since most of the applications I encounter in this capacity are mission critical applications it makes sense for me to have this checklist of things that I would discourage. As much as any other reason because it makes my job easier if I ever have to go back to the same company to do more consulting.

In short, although these things are important for someone like me, that may not necessarily be true for all ColdFusion developers.

Thanks for pointing that out Ben.

Spike

2002-06-24T07:52:00.000-07:00

Been very busy lately, so haven't had time to do much with the blog.

I've got lots of good material to add when I get a chance which should be sometime in mid July at current rate of mountain shifting.

Spike

2002-06-06T06:47:00.000-07:00

kwfu: ['MX','marketing','sales']

Great presentation on the MX vision from Jeremy Allaire now online:

http://www.macromedia.com/software/mx/presentation/

2002-06-05T08:38:00.000-07:00

kwfu: ['wait','sleep','delay']

Some tricks for getting a page to delay execution for a while on the server side while consuming minimum system resources. As opposed to looping infinitely which will cause processor peaks.

Force a lock contention and trap the resulting error - This one seems to be the best for versions prior to CFMX.

<cfset sleep = 2>
<cfset start = getTickCount()>
<cftry>
<cflock name="foo" timeout="#sleep#" type="ReadOnly">
<cflock name="foo" timeout="#sleep#" type="Exclusive">

</cflock>
</cflock>
<cfcatch></cfcatch>
</cftry>
<cfset time = getTickCount() - start>
<cfoutput>#time#</cfoutput>

Use cfexecute to invoke a process that either runs continuously, or doesn't stop for a while, and doesn't consume many system resources. This could also be done with cfftp, cfhttp, or a bunch of other external calls that are likely to take a while.

<cfset start = getTickCount()>
<cfexecute name="c:\cfusion\bin\cfstat.exe" timeout="2"/>
<cfset timer = getTickCount() - start>
<cfoutput>#timer#</cfoutput>

or

<cfset start = getTickCount()>
<cfset args = arrayNew(1)>
<cfset args[1] = '-n'>
<cfset args[2] = '1000'>
<cfset args[3] = 'localhost'>
<cftry>
<cfexecute name="c:\winnt\system32\ping.exe" arguments="#args#" timeout="5"/>
<cfcatch></cfcatch></cftry>
<cfset timer = getTickCount() - start>
<cfoutput>#timer#</cfoutput>

If you're running cfmx I'd recommend this.

<cfscript>
function sleep(timeMillis) {
var thread = createObject("java", "java.lang.Thread");
thread.sleep(timeMillis);
}
</cfscript>

2002-06-02T09:01:00.000-07:00

kwfu: ('custom tag','images','File upload')
Decided to post this custom tag I wrote a while ago. It reads the information from an image file and retrieves info such as file size in bytes, height, width, and some other file format specific info. Works for a range of file types such as tiff, gif, jpeg, ras, bmp, and png.

Download

Instructions:
1. Download file
2. Extract to directory under the webroot
3. Browse to index.cfm in the imgsize directory.

2002-05-23T15:09:00.000-07:00

kwfu: ('cfmx','pagecontext','jsp')
I think there are so many features like this in CFMX that there's going to
be a whole lot of re-learning and re-evaluating of what up to now have been
considered standard practices in CF, and probably more importantly things
which up to now have been considered more or less taboo.

I have some personal favourites from the 'Things that have changed'
department:
cfimport - allows you to have dynamic custom tag paths.
cftrace - Cuts out 90% of the cases where I'd be using cfdump/cfabort to
debug.
cflogin - allows multiple authentication mechanisms to fire the login code -
This could turn out to be a two edged sword, but there you go.

There are of course a whole bunch of new features like native XML support,
Flash remoting, CFCs etc.

As someone famous once said 'We live in interesting times'.

Originally posted on a closed mailing list. - Thanks Robi

UPDATE: Ray Camden pointed out that the multiple authentication mechanism is a feature you don't have to use.

Ray: you should note that this 'feature' of cflogin is
something you do not have to use. If you do not use the cflogin scope,
then you can restrict logins to just one source (form, url, whatever).
In other words, do not do this:

<cflogin>
<cfif isDefined("cflogin.name") ....

Use this:

<cflogin>
<cfif isDefined("form.name") ....

Spike: I guess I wasn't clear enough in what I was saying. Of course you could write code to handle this manually, but it's kinda nice to have the ability to accept logins from flash remoting and from form scope without so much as a cfif. This, of course opens up a whole bunch of problems like script kiddies who use dictionary files to attack sites secured with http basic authentication. That's where I see the 2 edged sword thing. In practice I would probably handle things manually for this very reason, but that may not be applicable in every situation.

2002-05-23T15:04:00.000-07:00

kwfu: ('cfmx','class files','compile')
This code will batch pre-compile a complete directory tree of CFMX templates. The original code is credited to an un-named Macromedia employee. He is only un-named because I haven't got round to checking with him if I can publish his name.

In ColdFusion MX:

Stick this in a batch file, save as compiler.bat, and pass it a directory to compile:

@setlocal
set NEO_INSTALL=c:\cfusionmx
set PATH=%NEO_INSTALL%\runtime\bin;%PATH%
java -classpath %NEO_INSTALL%\lib\cfusion.jar
coldfusion.tools.Compiler -webroot %NEO_INSTALL%\wwwroot %*
@endlocal

called like so:

compiler.bat c:\cfusionmx\wwwroot\myapp

Compiles all files below that directory.

Spike

2002-05-23T14:49:00.000-07:00

kwfu: ('cflock','cfmx')

The following code is credited to an un-named employee at Macromedia. The only reason he is un-named is that I haven't go round to getting his permission to use his name here. Suffice it to say that he is one of the core team of engineers who put together the ColdFusion MX engine. What he has to say is probably well worth listening to.




<cfset session.cartTotal = session.cartTotal + currentPrice>


Make your own mind up if you still want to use cflock.

Spike

2002-05-23T14:40:00.000-07:00

kwfu: ('cf','cflock','full checking')

In some versions of ColdFusion Server, there is an option in the ColdFusion Administrator related to the locking of shared memory variables. One of the options allows you to tell the ColdFusion Server to check all the code it processes to ensure that shared memory variables do not suffer from memory corruption. The option in the CF Administrator is referred to as 'full checking' in the following ramblings.

beware of trusting the results of turning on full checking...

If you do this:

<cflock scope="session" type="readonly" timeout="2">
<cfset userprofile = session.useprofile>
</cflock>

Then later in your code you do this:

<cfset userprofile.emailaddress = 'bob@somedomain.com'>

You are actually modifying the data in the session scope, but the full
checking will not pick it up.

In order to stop this being a problem you could do 1 of 2 things:

Option 1:
<cflock scope="session" type="readonly" timeout="2">
<cfset userprofile = duplicate(session.useprofile)>
</cflock>

This will create a completely separate copy of the userprofile. Depending on
what you are doing you might want this.

Option 2:
<cflock scope="session" type="exclusive" timeout="2">
<cfset userprofile.emailaddress = 'bob@somedomain.com'>
</cflock>

This will safely update the data in the session scope. Again, depending on
your circumstances this may be what you want to do.

Good luck hunting down blocks of code that need to be locked as in option 2.

Spike

Originally posted in response to a thread on the UK ColdFusion User Group mailing list: dev@lists.cfdeveloper.co.uk.

2002-05-23T13:34:00.000-07:00

kwfu: ('cf','application','cflock')

Some may find the following mutterings on the ColdFusion application and locking framework useful.

A variable which is created in application.cfm like so:

<cfset myvar = "Foo">

Does not get created in the application scope. It gets created in the
variables scope.

Since application.cfm gets auto-included at the start of every page request
this variable becomes available, as myvar, or variables.myvar, to the
template which was requested on the url, and any other templates which are
called by cfinclude. The variable will not be available to any templates
which are called as custom tags unless you explicitly pass it in there as an
attribute.

If you want the variable to be available to all templates you must
explicitly put it into the application scope like so:

<cfset application.myvar = "Foo">

This will be available to all templates as application.myvar, but not as
myvar, or variables.myvar.

In order to maintain data integrity, and for stability you must wrap reads
and writes to the application scope in a cflock:

Setting:
<cflock scope="application" type="exclusive" timeout="1">
<cfset application.myvar = "Foo">
</cflock>

Reading:
<cflock scope="application" type="readonly" timeout="1">
<cfoutput>#application.myvar#</cfoutput>
</cflock>

In CF 4.5, the Request scope was added so that the gazillions of custom tags
that Spectra uses could all access data safely without having to put cflocks
everywhere, or passing all the data around as attributes to the tags.

The request scope is also available to all pages which get executed for a
single request, so you could quite safely do this:

In application.cfm:
<cfset request.myvar = "Foo">

In some custom tag:
<cfoutput>#request.myvar#</cfoutput>

Woo Hoo!!!

No locking required...

BUT...

Since there is a new request scope for every user, you will be having a
separate copy of the data in that scope for each concurrent request. The
default maximum for concurrent requests is 6, so you will probably be having
up to 6 times the amount of data in the request scope in memory on a busy
server. If you have a lot of data in there, this can become siginificant, so
it's something to watch out for.

Apart from that, it's up to you what you'd prefer. Request or application
scopes are available to all files which get processed in a request, but you
can't read variables from them unless you specify the scope name explicitly.
This is probably a good idea anyhow, but most people, myself included, are
just too lazy to do it for all variables.

Spike

Originally posted in response to a thread on UK ColdFusion User Group mailing list: dev@lists.cfdeveloper.co.uk.