Download Firefox -  a safer, easier to use web browser. Return to iribbit.net - Leap into the online experience! Return to iribbit.net - Leap into the online experience! iribbit.net - Leap into the online experience!

Project News :.

The latest project to launch was the site for Gorilla Offroad Company. Aside from their main site, a social media strategy was develop to launch the company into various industry specific automobile enthusist discussion board communities as well as popular social media fronts like Facebook, Pinterest, and Twitter.


Valid XHTML 1.0 Transitional

Valid CSS!

Section 508 Compliant

powered by: Macromedia ColdFusion MX

made with: Macromedia Dreamweaver MX

What is RSS

XML - often denotes RSS Feed information.

Macromedia - ColdFusion Programming
white horizontal rule

ColdFusion News :.

To bring a little life to my site, I've pulled a couple What is RSS Feeds into this page. You can currently choose between the technology related news stories from the following news sources:



You are currently viewing and RSS Feed from coldfusionbloggers.org.



Cloning RegExp (Regular Expression) Objects In JavaScript
Ben Nadel looks at a way to clone Regular Expression (RegExp) objects in JavaScript, with additive flags....
(Thu, 24 Jul 2014 10:00:17 GMT)
[view article in new window]

Survey: to scope or not to scope
G'day:
And, indeed as the old trope goes: "that's the question". I have been looking at some code that follows one coding standard, which says "thou shalt scope all variables". And I look at my code, in which I only scope when needed, and I really feel the former is a pile of... clutter compared to my own code.

However the scope of my own code is much narrower and much less mission critical. And only I work on it. So just because I prefer to do something a given way which specifically suits me doesn't mean that's the best way to do it.

So I want to know how you do it. And with that in mind, here's a survey for you to fill out, if you so choose: "Scoping of variables scope variables".


Personally I think there's merit in scoping everything else: I'll scope form & URL variables despite the fact they're part of the scope-look-up that CFML does automatically. I think it's important to know where these external values came from. And obviously most other scopes need to be specified anyhow.

But what about the variables scope? I can see a point in scoping 'em in a CFC, as one wants to know when a variable is local (unscoped), or specifically object-wide: variables scope.

However in a CFM file I think it's ceremony for the sake of it.

What do you think?

The survey has three questions:

  • How vigorous are you at scoping variables-scope variables in CFM & CFC files?
  • Do you have either a formal or personal coding standard you follow regarding scoping of variables-scope variables?
  • Anything else to add?

So should be quick.

And - to make things abundantly clear - do not answer the questions in a comment on this article. Fill in the blimin' survey. That's what it's there for. All comments on the survey will be published when I follow-up in a few days. But if you comment here it wastes my time when I come to aggregate the result, as I have to grab them from multiple locations.

Cheers.

--
Adam
(Thu, 24 Jul 2014 08:11:57 GMT)
[view article in new window]

ColdFusion Builder Updated
ColdFusion Builder 3 Update 2 has been released. It addresses a series of issues, as defined in this post. The team has also posted some notes on ColdFusion Builder 3 automatic updates notification and installation options.
(Thu, 24 Jul 2014 08:00:05 GMT)
[view article in new window]

Dopefly is on ColdFusion 11
The title says it. Thanks to that wonderful human being Steven Benjamin, I've got a much newer CF to play with. We're a couple versions back at work, still, so it's really nice for me to get actually new technology one in a while. Thank you Steven!
(Wed, 23 Jul 2014 20:00:12 GMT)
[view article in new window]

Converting Fusebox 3 Sample App to ColdBox MVC

In our last installment, we talked about the benefits of converting legacy FuseBox applications over to ColdBox MVC. In this entry we'll actually convert the Fusebox 3 sample app available from fusebox.org to show you the similiarities and differences between the two frameworks.

Overview

Here's a screenshot of the files in the Fusebox and ColdBox code side-by-side. Both are pretty self-explanatory, so we'll work our way through the contents of each file as we go.

One of the first things you may notice is many of the Fusebox files have a prefix in their names such as "dsp_". You can do this in ColdBox if you wish, but we prefer to use folders to denote what a file does. For example, any file in the "views" folder is going to be for display purposes. Also, note the fbx_savecontent.cfm file is a custom tag only needed for compatibility on very old versions of ColdFusion so there's no need for an equivalent in ColdBox.

Core Framework

On the left, the "fbx_fusebox30_CF*.cfm" files represent the core Fusebox framework. There are different files for different versions of ColdFusion servers and operating systems. On the right, the "coldbox" folder contains the framework. The easiest place for this folder to live is in your web root so CF will automatically resolve CFC paths that start with "coldbox" there. For the security-minded, you can also move the folder elsewhere and create a server or app-specific mapping that points to it. This is especially handy if you have multiple ColdBox site and want to only maintain one copy of the framework.

Bootstrap

Both Fusebox and ColdBox use the concept of a "front controller". Basically, this means that all requests are directed at index.cfm, and then the framework kicks in and decides what actual code to run based on URL parameters or default settings. The way the Fusebox framework gets loaded is by a cfif statement in the index.cfm file that detects the version of CF and the operating system and includes the appropriate file. The ColdBox app has an index.cfm file, but it is an empty placeholder. ColdBox leverages the application, session, and request lifecycle methods that are part of Application.cfc. If your legacy site uses Application.cfm, you'll need to convert this over.

index.cfm


Application.cfc

component extends="coldbox.system.Coldbox" {
this.name = 'FuseBoxSampleConversion';
}

You'll notice that Application.cfc extends the core ColdBox component. This component implements methods such as onApplicationStart() and onRequestStart() to load up the framework and process requests. If you ever need to add methods to Application.cfc, make sure you continue to call the super-scoped method as well. If you want to use an app-specific mapping for "/coldbox", you'll need to use our non-inheritance template. Read more about this here.

Settings

The Fusebox app uses anfbx_Settings.cfmfiles that contains settings for the app. In ColdBox, we have a "/config" convention folder where we place all our configuration. There are several files that can eventually be put in this folder if you begin using WireBox, LogBox, etc but by default all you need is a CFC calledColdBox.cfcin there. The only requirements of this file is that it contains a method called configure() and defines a variable called coldbox.appName. There are a number of optional settings you can define here as well additional methods for environment control that override settings for you automatically on your development or staging servers. You can read about this here.

fbx_Settings.cfm

 I was very excited that Axel was able to attend all the way from Munich, as he is well known expert on ES6 (and author of the new book "Speaking JavaScript".

During my time at the conference I was able to interview Axel. We mostly discussed the process whereby new features are added to the ES6 spec, using JavaScript for enterprise development and which features Axel is most excited about in ES6.

So what two features did Axel choose as his favorites in ES6? I think you may be surprised, but you'll have to watch or read the interview on InfoQ to find out.


(Wed, 23 Jul 2014 14:00:17 GMT)
[view article in new window]

jsFiddle Example: Proper Timeout Handling with AngularJS
AngularJS has a really poor handling of timeouts, at least for complex HTTP calls. You can provide a timeout in milliseconds, but if the request does time out, you just get a cancelled request. Now this might be fine for simple situations, but when you have CORS Ajax calls, you end up not being able to tell a timeout from a CORS request. This can be handled by switching to setting the timeout with a Promise instead. This code shows how to use a promise for your timeout in AngularJS to get clear error messages.
The createData() function is purely to work with jsFiddle's echo API.

(Wed, 23 Jul 2014 14:00:14 GMT)
[view article in new window]

Finally had a chance to look at Sean's version of case()
G'day:
This took way longer to revisit than I intended. Apologies to Sean, as it might have seemed like I solicited some code from him and then ignored it. And, indeed, that was mostly the case other than an initial peek and a "hang on... what? How the? But... oh, I think I see..." and a conclusion my assessment of it needed more than 2min.

Right, so a coupla weeks back I wrote and article "Some more TestBox testing, case/when for CFML and some dodgy code". This demonstrated some code (and its tests) that I was messing around with that implemented a case/when/then/else function in CFML. That'll make more sense if you read the article.

Sean had a look at it and could see some simplifications which could be made, and popped a revised version through to me via Github ("adamcase / case.cfm"). As I alluded to above, my initial parsing of the solution just made my eyebrow raise - Spock-like - and other than that I saw what he was doing, but not how it worked (and it did work; the relevant tests still passed). Today I sat down and had a look at the code, and made myself understand it. And I like it.

Here it is:

// case.cfm
struct function case(){
var requireCondition = function(condition){
condition ?: throw(type="MissingArgumentException")
!isBoolean(condition) && !isCustomFunction(condition) && !isClosure(condition) &&
throw(type="InvalidArgumentException")
}
var requireValue = function(value){
value ?: throw(type="MissingArgumentException")
!isCustomFunction(value) && !isClosure(value) &&
throw(type="InvalidArgumentException")
}
return {
when = function(condition){
requireCondition(argumentCollection=arguments)
if ( isBoolean( condition ) ? condition :
( condition() ?: false ) ) {
return {
then = function(value){
requireValue(argumentCollection=arguments)
var ender = {
end = function(){
return value() ?: javaCast("null","")
}
}
var whenner = { }
var thenner = {
when = function(_){ return whenner },
else = function(_){ return ender },
end = ender.end
}
whenner.then = function(_){ return thenner }
return thenner
}
}
} else {
return {
then = function(_){
return {
when = case().when,
else = function(value){
requireValue(argumentCollection=arguments)
return {
end = function(){
return value() ?: javaCast("null","")
}
}
},
end = function(){ return javaCast("null","") }
}
}
}
}
}
}
}

The chief difference between Sean's version and my version is that he made a very salient observation: my code continues to enforce the validity of the when() condition and the then() (or else()) value even after the condition had been met and the value had been decided upon. Or similarly I was validating the value of a then() even when its related when() condition was false. To clarify, here's an example:

result = case()
.when(thisIsFalse).then(value1)
.when(thisIsTrue).then(value2)
.when(thisIsAlsoTrue).then(value3)
.else(value4)
.end()

Here the green bits are things we care about, the red bits are things we don't need to care about.

  • we care about the when() condition being valid until a condition is met. After that, it doesn't matter, because we have already found our value. So we can safely stop validating or paying any attention to subsequent conditions;
  • we do not care about the value of a then() if the associated when() condition is false;
  • in fact the only value we care about is the first one immediately following a true when() condition; or the final else() if no conditions get met. The rest of the time we can ignore them completely. They don't need to be "valid" as we will not be using them.

So Sean uses two different versions of each of when(), then() and else().

Also interestingly he dispensed with a lot of my code which determined which functions to return, and in the process made the code a lot tighter. And, thirdly, a side effect of all this is that there's no need to pass-the-parcel with flags showing if the condition had been met, and if they value had been met. He simply remembers which value function was the one from the appropriate then() or else() call, and returns it from end(). As the when() and then() calls only do anything for as long as they need to to find that value, there's no need to tell subsequent when() / then() calls whether they need to execute or not. They can just execute, because they don't do anything. Simple.

Let's revisit the code again, with some annotations.

var requireCondition = function(condition){
condition ?: throw(type="MissingArgumentException")
!isBoolean(condition) && !isCustomFunction(condition) && !isClosure(condition) &&
throw(type="InvalidArgumentException")
}
var requireValue = function(value){
value ?: throw(type="MissingArgumentException")
!isCustomFunction(value) && !isClosure(value) &&
throw(type="InvalidArgumentException")
}


Sean's reversed the logic here. I had this:

isBoolean(condition) || isCustomFunction(condition) || isClosure(condition) ? true : throw(type="InvalidArgumentException")

I like Sean's approach because it gets rid of the ?: and the placeholder true, but has the added bonus of short-circuiting the logic tests. As soon as the condition is deemed valid, that's it. If, on the other hand, we get all the way to the end... the exception still raises. Nice.

Those were the easy bits.

return {
when = function(condition){

case() always needs to return just a when(). Because the only thing that's valid to call from a case() is a when(). One cannot do case().then(), or case().else(), or case().end(). So we need no logic as to which functions to return here.

if ( isBoolean( condition ) ? condition :
( condition() ?: false ) ) {
return {
then = function(value){
// [etc]
}
}
} else {
return {
then = function(_){
// [etc]
}
}
}

Here it gets clever. Everything about how things process changes depending on whether the condition is true or not. If the condition is true, we need to grab the value from the following then() call, and we don't need to do further processing after that, until we get to end() (which will return this value). However if the condition is false, our then() can just be a placeholder (as we already know we're not interested in its value), but we do need to still remember how to do a when(), then(), else() should we have further calls to them which might need to do something.

Let's look at the then() created by the true path:

then = function(value){
requireValue(argumentCollection=arguments)
var ender = {
end = function(){
return value() ?: javaCast("null","")
}
}

var whenner = { }
var thenner = {
when = function(_){ return whenner },
else = function(_){ return ender },
end = ender.end
}
whenner.then = function(_){ return thenner }
return thenner
}

  • first it needs to validate its value (as per further up)
  • now a then() can be followed by an end() (when().then().end()), so we need to define that. What end() will (always) do is to return the value() function's value. Or null if there was no condition met, so no value to run.
  • and if the condition was true, we have finished using when(), then() and else(), so they can just be stubbed.
  • There's a slight bit of recursion here: subsequent calls to when() will still need to return a then(), and that then will need to return when(), else() and end(). So we use references to build all the eventual responses from the stubbed functions and the real end() function. It's this bit that did my head in for a while.

Now for the false path:

return {
then = function(_){
return {
when = case().when,
else = function(value){
requireValue(argumentCollection=arguments)
return {
end = function(){
return value() ?: javaCast("null","")
}

}
}
,
end = function(){ return javaCast("null","") }
}
}

}

Here the condition wasn't met, so:
  • whilst we do need to return a then() function, we don't need it to process, so it's stubbed.
  • However whilst stubbed, that then() does still need to all fully-functional processing to resume with the next when() call in the chain, and the easiest way to set what that does is... call the case() function afresh and use its when() function. Very clever.
  • We might - at this point - need a functional else() function (we didn't on the true path, as it would never be needed, as the when() condition had been met), so it's defined to simply "return" the result of its value argument (or explicitly null if it returns no value)...
  • ... by implementing an end() function which returns its value().
  • Finally the end() function which might follow a false-conditioned when() will - intrinsically - not have ever received a value(), so a null can be returned from that too.
I wonder if that explanation made sense? Having explained in writing, it makes perfect sense to me now, and I'm bloody impressed. It's amazing what one can do with some nested references and a small amount of recursive thinking. I am certain I would have never - in a million years - come up with a solution like this. Nice one, Sean!

--
Adam
(Wed, 23 Jul 2014 13:20:26 GMT)
[view article in new window]

ColdFusion null pointer problem in ColdFusion 10 & 11 could it be a serious problem!

For a long time I have been seeing a lot of errors in my Application logs, that has had me stumped for a very long time and thanks to Brad Wood, have now got a reproducible solution. For those who haven't seen my rants and raves about this then let me give you a quick run down.

There where two types of errors that would be emailed to me in my actual site, due to the amount of times I was seeing this error it had me worried. I could not see from the email as to what the actual problem was, when I contacted my hosting provider all I ever got was that we don't see this in the ColdFusion logs. So it was hard to know if I was the only one having this issue or not, or like everyone else om my hosting provider capturing the logs and not knowing what or how it was occurring.

As a well ColdFusion should be aware of any serious errors it is causing, this lead me to raise a ticket so that people on hosting servers, would not have to report this error or any other error that ColdFusion itself would consider a serious error. Which got such a back lash by people who, well just didn't understand what the ticket was for, anyway aside from that Brad did a very quick test on a standard two file Application for ColdFusion.

The code is as follows.


(Wed, 23 Jul 2014 12:00:09 GMT)
[view article in new window]

An example of Cordova's Camera PopoverOptions
One of the interesting features in Cordova's Camera API is something called popoverOptions. While the docs do explain what this feature does, it may not be entirely clear how it works so I whipped up a quick example, with screen shots, to demonstra...
(Wed, 23 Jul 2014 10:00:15 GMT)
[view article in new window]


© The connection to the COLDFUSIONBLOGGERS's RSS feed has timed out - please try again later. We are sorry for any inconvenience this may have caused.