This Thursday http://www.cfug.org.nz/ and http://www.fxug.org.nz/ are hosting an Adobe Roadshow event with Mark Szulc.

Come along to hear more about Flash Builder, Flash Catalyst and CF9!

I will attempt to broadcast the meeting on http://experts.na3.acrobat.com/nzcfug/, all going well!

Related Links:

http://groups.adobe.com/posts/1b5f77b054

http://nzroadshow.eventbrite.com/

http://labs.adobe.com/

See you there!

I've been working on a project a bit lately and found I've had the need to use some constants.

This has gotten me thinking how to implement them.

When work in Flex, I use the Extensions for Adobe Cairngorm and when creating your custom events involves you declaring constants in the event. The consts in the event are related to the Event type.

The idea behind constants is that this is information that *will never change*, hence the name "constants" :-)

In the CF application I've been working on, UUIDs are used, and there is no way you can call a UUID "human readable", so this can make code harder to understand when you see something like:

If you want the person who reads this code later understand which page that is with out having to pull the application apart (and hair out too sometimes), you might to this:

That way the name of the variable will indicate *what* that UUID value indicates.

With me so far?

"But Dave, my application has more than one template and I don't want to have to do that every time I want to send a user to the info page, and what happens if the UUID of the info page changes?" you cry.

Well, why not have a single "thing" that stores all your constants that you can store in one place and use everywhere?

What I started doing here is I created a "Const.cfc" that had getter functions on them to return the constants. EG:

(Another note: I'd usually declare/call the function in all CAPS too, as this is the "standard" way of naming constants)

The above relies on "oConst" being created, which could be stored in application scope for example.

What I didn't like about this is that the actual value is hidden from my old friend "cfdump", and if I have alot of constants I can't see their values in one hit.

This lead me to the "this" scope of my CFC(s).

Something like this:

...which them means the example code can be written like this:

Before you cry "But people can change the values in the 'this' scope and break stuff!", I've always thought if people want to do that, it's up to them, but don't come running to me if it breaks! (Also, CFCs are not secure at all anyway! see related entry)

The two things I like about using the "this" scope for constants are:

• 1: You can see all the values if you cfdump it
• 2: If you CFC has functions, you don't have lots of functions to work out that don't really do anything

Let me explain the second point a bit further.

Imagine I have a DB table that stores information of pages on my site. My CFC has functions to work with this data. In my application I have 1meeeeeeelllion UUIDs to do with various parts of the application, that are used in various ways, that would help the readability of my code if they are stored as constants. This would render the "One Constant.cfc to rule them all" a bit hard to manage. What I have been doing is storing the UUIDs to do with that part of the application in the CFC that deals with that part of the application.

EG:

If you create that cfc and dump it as below:

Given the above code uses no frameworks and if any of you managed to read all my brain dump, what thoughts do you have on the above and/or how have you approached ColdFusion constants?

Disclaimer: all the above code is psedo code and hasn't actually been tested, but feel free to point out syntax errors etc. I may change it, I may not...

I've been looking in to Mark Mandel's Transfer bit since he presented to the http://www.cfug.org.nz end of last year.

One thing (of the many things) I like about it is the XML config file.

Why do I like it?

2 reasons.

1. The fact you can introduce some form of package.class hierarchy to the Database, so flat database's can be organized better EG:

2. The second reason is: I CAN COMMENT THE XML! Why is this good? I'm sure we have all returned to database tables with a few to many columns and tried to would out what "status" column and "anotherStatus" column actually relates to in the business logic of the application. This process involves digging through code and random comments. With the XML config of transfer, a simple comment on the property can explain it so the next person who needs to work with it knows where look to find out what the class (db table) is for and what purpose the property servers.

Hopefully I'll find the time to blog some examples on Transfer later.

EG: Event model and decorators

Only 2 days till the next NZ Cfug meeting.

This month we are going to have Mark Mandel giving us his "Introduction to Building Applications with Transfer ORM" presentation live via Adobe Connect.

We attempted to have this last month, but due to technical issues last month [cough]VPN[cough] Mark agreed to give it this month.

This month we are meeting for the first time at ProjectPartner, so a big thank you to them!

The meeting will be broadcast via Connect on the URL http://experts.na3.acrobat.com/nzcfug/, so feel free to sit in if you are round @ 6pm (NZ time) on the 6th November.

If you RSVP (remote or in person) and are based in NZ, you'll be in the prize draw too!

RSVP: http://nzcfug.eventbrite.com/

See you there!

The last week or so I've had the pleasure of working deeply with jQuery.

And I mean that, it's been a pleasure.

Once you get used to the 'style' of how it works, it makes sense and has a consistent coding experience.

I've worked mainly with the core and the ui.jquery libraries, with fileupload thrown in. In the mix is also , and they have all played together nicely (so far!)

I've got jQuery adding and removing custom DOM elements on the fly, while updating information on the server, uploading and deleting images and also maintaining the structure of the form so that when it is submitted in the usual "post" manner, the server knows what to do with the data it receives.

So all in all I've had a good experience with it.

Things it has helped me understand is the use of "anonymous Functions" (I think that is what they are called)

EG:

now the "hide" method will accept an argument of a function that it will call when it has completed. Commonly called a "callback", so i we had a function like this:

To use an anonymous function to do the same thing, this is what you would do:

You can also do this in Flex.

eg:

rather than:

One thing that works, but somehow feels wrong, is that the anonymous functions have direct access to the variables declared in the calling function.

eg:

So all in all I've enjoyed getting to know jQuery, and suspect it's the beginning of a beautiful friendship!

...but, I still prefer Flex!

Tonight we had the honor of Ray Camden staying up till 1am his time to present to us @ 6pm NZ time.

The meeting was the NZ ColdFusion UG June meeting, and the topic was CF8 Ajax Goodness

After a couple of technical issues (involving screen issues and incorrect Connect meeting rooms on my part...*cough*) we got the meeting under way.

Ray, as always, gave a great presentation which promoted good discussion in the group afterwards.

So a big thanks to Ray for his continued giving of time and energy to the community!

The recording URL is https://admin.adobe.acrobat.com/_a200985228/p21985414/ and I have also added it to UGTV

Enjoy!

I while ago I logged a bug for the first time with in ColdFusion 8.

Here is the entry about it.

While looking over the 8.0.1 release notes I decide to check...

and yes, at the top of page 15, bug number 70594 has been addressed! Thank you!

Just noticed this on a mailing list:

Transfer 1.0 Release Candidate - Out Now!

Well done Mark!

Mark presented to the NZCFUG last year on TransferORM.

I'll be downloading Transfer 1.0 soon to have take it for a spin!

I was working with a CFC today and ColdFusion threw this error at me:

can't load a null

There was no more information than that...

I'm not sure why is this error happens, but I did work what is causing it...

If you define a function that has an argument that has a default that is a variable or function with the same name as any of the arguments, this error is thrown.

You don't even need to call the function, you just need to define it.

Create a .cfm or .cfc and put this function in it:

The error is occurring when ColdFusion is parsing the code, and not running it.

Weird eh?

I'm off to http://www.adobe.com/go/wish now to log a bug (all-be-it an obscure odd one...)

Last Thursday at the NZ CFUG group we tried something new.

For the first time we watched a recording of a Connect meeting and had discussion about it once it finished.

After voting by the CFUG members for the topic, "Practical Code Generation" by Peter Bell was chosen.

About this Presentation (taken from UGTV):

A 20-30 minute preview session of my full session where we'd learn how to generate your applications in a fraction of the time by using the latest techniques proven to reduce application development times - from Software Product Lines to Domain Specific Languages.

The meeting was given to the "Online ColdFusion User Group" a couple of months back.

I've heard the phrase "Domain Specific Languages" (DSL) thrown round a bit and generally I nodded my head hoping the person using it wouldn't ask me about it, as I didn't really know what it meant...

In the presentation Peter took some pains to explain what a DSL is and how they can be used in code generation.

I found it to be a highly information presentation, so kudos to Peter Bell for this and also Charlie Arehart for running (and recording) the meeting

The link to the recording is here: https://admin.acrobat.com/_a204547676/p26665304/, so have a look when you get a chance!

PS: there can *never* be enough TLA's in the world! *NEVER*!

Rupesh Kumar (a member of the ColdFusion engineering team) has just blogged about surveys for input on the next version of ColdFusion!

Go here - http://coldfused.blogspot.com/2008/01/adobe-coldfusion-survey.html to find the surveys and give the CF team some good ideas on the next version of CF!