Coder's Revolution

Do you want a revolution?

Category Filtering: 'CF'

Exciting New Features In The CommandBox 3.1.0 Bleeding Edge

ColdFusion, CommandBox, Lucee, Railo
Hi all, we've been hard at work on ForgeBox 2.0 and the corresponding CommandBox CLI features that focus on your productivity in publishing packages and keeping them up to date as well as tracking all the versions of your dependencies.
For starters, the ForgeBox 2.0 isn't published yet in production.  If you download the bleeding edge of CommandBox (3.1.0) you will be pointing to our stage server.  it's a recent backup of production data, but since the new ForgeBox site is a rewrite on top of an updated data structure, it needs to be a separate database.  So, feel free to use it, but remember you're not going to be installing or publishing to the live ForgeBox site yet until we roll out this release.
Download CommandBox 3.1.0 here:
Running "upgrade --latest" will also give you this URL.
Here's an overview of the new stuff for you to try out:

New ForgeBox 2.0 API

The API has been rewritten as a fresh ColdBox module using ORM and a new database.  You probably don't really care since the endpoints are mostly the same, but nonetheless it all needs tested to make sure we didn't break anything.


Track more than one version of your package at a time in ForgeBox

As part of the new data structure in the ForgeBox site, a package no longer has a single version, but as many versions as you like.  Each version stores its own download URL, and box.json data.  The new site will show these.  For now you can see the available versions from the CLI with the "forgebox show" command:
CommandBox> forgebox show coldbox
ColdBox Platform ( Luis Majano, [email protected] ) *****

The ColdBox MVC Platform manual can be found here: 

Type: MVC
Slug: "coldbox"
Summary: The ColdBox Platform
Versions: 4.3.0-snapshot, 4.2.0, 4.1.0, 4.0.0, 4.0.0-rc, 3.8.2, 3.8.1, 3.8.0, 3.7.0



Create user from CLI

Also part of the new API is the ability to create a new ForgeBox user right from the CLI.  Run the "forgebox register" command to get started.  Feel free to test this, but if you already have a ForgeBox user, you can just skip to the next step and login.  The confirmation E-mail is bypassed right now for testing.  If you forget your password on our stage server, there's not currently a way to reset your password, but there will be.  


Authenticate from the CLI

Once you have a confirmed user, you can run "forgebox login" to authenticate your account.  This will store your API key in a CommandBox config setting.  You can see it with:
CommandBox> config show endpoints.forgebox


Bump tags Git repo

This is a nice feature that npm does.  When you use the "package version" command (aliased as "bump"), if you are running the command in a Git repository and the working directory is clean, the CLI will create a tag for you that's named after the version and commit it.  You can supply a custom message if you like each time or as a global setting and even turn the entire feature off with a config setting flag.
CommandBox> bump --patch
CommandBox> bump --minor message="Upgrading to ${version} because I want to"
CommandBox> config set tagVersionMessage="My default tag message"
CommandBox> config set tagVersion=false


Publish packages from the CLI

This is where it really gets fun.  You basically don't ever need to touch the forgebox website again if you don't want to!  The "forgebox publish" command (aliased as "publish") will add a new package to ForgeBox, or update an existing one (that belongs to you).  If the local version number is different, a new version will be created in ForgeBox.  Usually you would use the bump command above right before publishing.  Remember, ForgeBox does not store your actual package files like npm.  We just point to your download location.  We've been optimizing this as much as possible to work seamlessly with a Git repo. When you publish a package, this data is sent to the server:
  • Your box.json.  Specifically
    • Package name
    • slug
    • version
    • type
    • location (this is where to download your package from and can be an HTTP URL or ANY VALID package ID such as "repoUser/repoName#v1.2.3")
    • etc
  • The contents of your readme[.txt|.md] file one of those exists
  • The contents of your changelog[.txt|.md] file one of those exists
  • The contents of your instructions[.txt|.md] file one of those exists
  • Your API key config setting to authenticate
That's it.  Once you run this command, you can run "forgebox show my-package" to confirm it's there.  
Any updates to your readme, title, etc will overwrite the old data.  
If you change the slug, a new package will be created.  
If you change the version, a new version will be added to the existing package.
I've run a backfill on the new ForgeBox database to create a single version on every package equal to whatever the last version was saved in ForgeBox.

Semantic Versioning support

This is huge and goes hand-in-hand with the new versioning.  One of the biggest complaints about ForgeBox is you couldn't say "install [email protected]" if the latest version of foo was actually 2.0.0.  Well, now you can.  Any version on a ForgeBox package which is typed after an @ sign for the install command or as the "value" of your dependency in box.json will now be used to look up the correct version in ForgeBox (assuming it exists) and the proper download URL will be used to download and save it in artifacts.  Remember, the download URL comes from the "location" property of the box.json and can be any valid packager ID.
And that's not all-- we now fully support the entire implementation of npm-style semver ranges.  That means you tell CommandBox a "fuzzy" range of versions you're ok with and it finds the best match.  Stable versions are determined by the existence of a pre-release ID like "-alpha".  Therefore 1.2.3-rc is a pre-release but 1.2.3 is a stable build. 
Here's some examples:
# Latest stable version
CommandBox> install foo

# Same as above
CommandBox> install [email protected]

# latest version, even if pre release (bleeding edge)
CommandBox> install [email protected]

# A specific version
CommandBox> install [email protected]

# Any version with a major number of 4 (4.1, 4.2, 4.9, etc)
CommandBox> install [email protected]

# Any version greater than 1.5.0
CommandBox> install foo@>1.5.0

# Any version greater than 5.2 but less than or equal to 6.3.4
CommandBox> install "foo@>5.2 <=6.3.4"

# Any version greater than or equal to 1.2 but less than or equal to 3.2
CommandBox> install "[email protected] - 3.2"

# Allows patch-level changes if a minor version is specified. Allows minor-level changes if not.  (2.1.2, 2.1.3, 2.1.4, etc)
CommandBox> install foo@~2.1

# Any greater version that does not modify the left-most non-zero digit.  4.2, 4.3, 4.9, etc
CommandBox> install foo@^4.1.4


And finally, the "update" command really works now as it takes the semver range stored in your box.json into account.  For example, if you have a dependency installed with a version saved of ^2.0.0 it will update you all the way to 2.9.9 but it will never install3.0.0 until you ask it to.  This is because breaking changes come in major versions, but minor releases are supposed to be compatible.

Interceptor-based CLI scripts

Moving along, we've borrowed another idea from npm's run-scripts.  We allow a struct in your box.json that can define named scripts comprised of CommandBox commands.  We've hooked these scripts up to all the built-in interception points in CommandBox (and added a few new ones) so you can prescribe arbitrary commands on a package-by-package basis to run any time you bump a package version, publish to ForgeBox, start a server, or exit the CLI.
Here's an example box.json file:
  "name" : "My Package",
  "slug" : "my-package",
  "version" : "1.0.0",
  "scripts" : {
   "postVersion" : "package set location='gitUser/gitRepo#`package version`'"
   "postPublish" : "!git push'"

Any time I bump a package version, I'll update the location property to have the latest version for the Git tag.

And when I publish my package in ForgeBox, I'll automatically push my changes to Github (assuming I have a Git client installed at the command line)


System log command

This is a small one, but the new "system-log" command outputs the path to the CommandBox log file. You can use it creatively by piping its output into other commands:


CommandBox> system-log | open
CommandBox> system-log | cat
CommandBox> system-log | tail


Lots of little bug fixes

There's a number of small things we've fixed here and there that you can see in JIRA.

Coming very soon- multi-server support!

We are also working hard on the ability for you to not only start up Lucee 4.5 servers but also:
  • Adobe CF 
  • Lucee 5.0
  • Railo 4.2
  • Any random WAR you want 
This will be part of the 3.1.0 release and I'll post here again when it's ready to try out on the bleeding edge.

Streamlined Productivity

I'll leave you with the FULL set of commands necessary to start from complete scratch, sign up for ForgeBox, authenticate, create a package, and publish it for all the world to install!

# Create user (first time only)
CommandBox> forgebox register username password [email protected] firstName lastName
CommandBox> forgebox login username password

# Create package/git repo
CommandBox> mkdir mypackage --cd
CommandBox> !git init
CommandBox> package init slug=my-package type=modules location=gitUser/my-package
CommandBox> bump --minor message="Initial Commit"

# Publish it
CommandBox> !git remote add origin <git url>
CommandBox> !git push
CommandBox> publish

# Viewable and installable by the world!
CommandBox> forgebox show my-package
CommandBox> install my-package



State of the CF Union 2016 Survey results are in

ColdFusion, General, Lucee

Michael Smith has released the full results of this year's State of the CF Union survey over on the TeraTech blog.  I enjoy seeing this data every year as a framework author since it helps us know what engines and types of OS to target with our products.  This year, there's a full write up and a little commentary on each graph.  Note the write up is spread across two blog entries:

Notable bits of data were:

  • CF9 is finally falling behind CF10 and CF11.  This is good since we'll be dropping support for CF9 in ColdBox soon
  • Lucee has left Railo usage in the dust, and a solid amount of people are already using Lucee 5
  • Still a lot of people out there using no framework at all or FuseBox!  Of course, I assume this isn't new dev, but rather the same old legacy apps that have been around for years
  • A lot of people not using a DI framework. Kind of curious if they're not using CFCs at all.
  • Really surprised how many people still use Notepad++ for dev.  
  • The "How many years have you used CFML" graph is very depressing.  Very little new blood coming into CFML.
  • Love how many people are using CommandBox.  I'm so pleased to see it being useful for the CF world
  • A decent chunk of Amazon EC2 users, but it's clear most CF shops aren't doing cloud deploys. Not sure if Adobe doesn't focus on cloud because their users don't care, or if it's the other way around.
  • Surprised to see how many home-grown REST frameworks there are. I can't imagine a world in which you wouldn't waste more time doing that from scratch than to drop in something quick and easy like ColdBox 4's REST routing.  There's so much out of the box to be gained.
  • There's a decent chunk of CF devs in very large companies, but the majority are in small business's with 1-20 total employees.  That's interesting since it's not where I would have pegged most CF devs to be.
  • The comments are very interesting too.  Lots of love for Lucee and lots of frustration for Adobe.  

OK, well there's my thoughts. Head over and check out the data yourself. 


CFML & CommandBox, Tools Of Biblical Proportions

ColdFusion, CommandBox, Lucee, Railo, Technology

In the beginning was the Web, and the Web was with CFML, and the Web was CFML. It was with CFML in the beginning. Through it all websites were made; without it no websites were made that had been made. In it were tags, and those tags were the productivity of all programmerkind. The productivity shone in the darkness, and the darkness did not overcome it.

Ok, maybe I'm overstating CFML a bit, but when it was created it was revolutionary.  It redefined how websites were built and set the bar for other web programming languages.  And though CFML led the pack for a while, there were soon others to follow.  These languages were also productive, came with compelling frameworks, and made building sites fast and fun.  Many of these servers were also free and open source and around them large communities grew.  


Railo And Lucee: Hunka Hunka Burning Questions

CFML, ColdFusion, Lucee, Railo

Well, the cat is out of the bag now.  Railo, the free open source alternative CFML engine to Adobe's ColdFusion Server has been forked and reborn as a new product called Lucee.  I was lucky to be part of the launch party (via webcam) that happened this morning in London.  This is a major event in the tiny CFML eco-system and it's understandable that there's a  lot of questions floating around and confusion on just exactly what has happened.

There are a lot of large open source projects that have forked before.  For instance, MySQL spawned MariaDB, OpenOffice, begat LibreOffice, Hudson turned into Jenkins, and even recently Node.js was forked int IO.js.  In some cases, the original project continues alongside the new one.  In other cases, the old project basically sits there and everyone stands up, shuffles over to the new one, sits down and continues as if nothing happened.  I personally think Lucee is going to be more like one of those.

I'm throwing together this post to address some questions that have come up over and over again today.  Hopefully they will be answered more fully by the Lucee team as they dig out of this major announcement, but in the mean time this is a compilation of some answers I've given multiple times today around the Internets.  Please note, I am not speaking on behalf of Lucee nor Railo, these are my opinions and observations mixed with some info I've picked up along the way.  I'll happily accept corrects or clarifications in the comments.


CFClient: What's Your (Geolocation) Vector, Victor?

CFClient, ColdFusion, ColdFusion Builder, JavaScript, Mobile

In my last post I played with the Media API to add sounds effects to the Roll The Ball game and made an Adobe CF Soundboard.  Today I'll be showing my work with the Geolocation API.  I wish I had some more time to do something more useful, but the CF mobile contest is drawing to a close tonight and I this will be the last feature I have time to put in.


CFML, Good Discussions, And Misinformation

ColdBox, ColdFusion, CommandBox, General, Java, Object Oriented Design (OOP), Railo, Technology

So this blog is a bit of a spill over from a Twitter conversation I had today with Stefan Mischook, a PHP programmer and maker of all sorts of training videos at and  A few years ago, Stefan uploaded a video blog to YouTube titled "Should you learn Coldfusion?" (sic) where he presented a not-so-glowing review of ColdFusion through the lens of circa 2003.  I've seen the video before come up in YouTube searches.  Part of that is a testament to the pathetically small amount of actual CFML content on YouTube.  While I've recorded a number of screencasts and webinars that are posted online, they're all on Vimeo or Adobe Connect so alas I'm not contributing to that specific site.  


CFClient: Tuning Up The Accelerometer Gets Things "Rolling"

CFClient, ColdFusion, ColdFusion Builder, Mobile

In  my last post,  I tackled two APIs-- notifications and contacts.  Even though I wasn't able to fully explore the contacts, I managed to get things working without too much troubles.   I'm occasionally hitting some weird parsing issues in CFBuilder or underlying JavaScript errors I can't explain but "rearranging" my code will usually make it go away (more on this later).  I'll try to go back  and put in tickets for these after the fact, but I'm always reticent to shout "BUG!" in a crowded theater when I'm not 100% I'm doing it right.


Well, let's get right to it.  Today I played with the accelerometer API which is incredibly simple in terms of the API's surface area, but rather deep in applications. 


CFClient: We Have Contact, Let's Notify!

CFClient, ColdFusion, JavaScript, Mobile

My last entry was a little light on the client APIs and mostly spent (unsuccessfully) wrestling my HTML markup around.  So,  to make up for it, I've implemented 2 different client APIs.  That's right, two for the price of one!  The first was notifications which was pretty straightforward, followed by contacts which is kind of complicated-- well, let's just say "involved".

You may notice in the screenshots that the app is no longer full screen.  I didn't care for that so I found the fullscreen preference under the project's PhoneGap properties and set it to false.  This setting does not appear to be stored anywhere in the web root though, so if you check out the code into a mobile project of your own you'll probably have to set it yourself too.


CFClient: The Agony & The Ecstasy -- Making It Purty

CFClient, ColdFusion, ColdFusion Builder, JQuery, Mobile

In my last entry, I discussed my decision to  create a "CFClient Sampler" app that would simultaneously allow me to play with each mobile client API, all the while providing the community with some nature of blog-based documentary on my attempt.  With a solid proof of concept under my belt (and on GitHub) I pushed forward with two goals in mind this time:

  1. Pick another API to play with
  2. Figure out some organization for the code before it got out of hand
  3. Ok, I guess there was a third goal too:  Make it not so ugly.

I'll start with the last one, which was to make the app not look like a middle schooler banging something out with Microsoft FrontPage.  Quite frankly, I suck at UI stuff.  I'm a "function over form" guy and I'm quite happy architecting the back end of an application far far away from the perils of CSS, responsive layouts, and viewports.   For this I used my phone-a-friend and dialed up jQuery Mobile.  JQM has been around for a while and it doesn't make web pages that very unique (kind of like the BootStrap cookie cutter sites) but it's stupid simple to setup and covers every major navigation, button, control, and layout concern I'll be detailing with.  


My CFClient Proof Of Concept and GapDebug

CFClient, ColdFusion, ColdFusion Builder

So, in my first entry I discussed that I'm trying my hand at CFClient, mostly drawn to the idea of winning a $1000 gift card from Adobe.  Previously I followed Ram's YouTube videos and articles on setting up a Mobile project in ColdFusion Builder, installing his sample app, compiling that app via Adobe's cloud-based PhoneGap server, and installing it.

This venture was met with mixed success.  The PhoneGap shell app which allows one to test without needing to recompile after EVERY code change fell flat out of the gate for me.  I'm still waiting to hear back from Adobe on that.  I was able to compile and run the sample app, but couldn't get the file APIs to work.  I've sort of given up on that for now-- there's just not enough time to keep banging my head on that wall for the time being.