ColdBox has sported RESTFul capabilities since the 3.0.0 days (that's since 2011).  As each release matures, our RESTFul suite of tools mature as well.  In our latest release we introduced a great way to intercept when RESTFul endpoints are called with invalid HTTP methods.  Every ColdBox handler has the this.allowedMethods structure which can tell the framework what actions can be executed with what HTTP methods.

this.allowedMethods = {
  index = "GET",
  save = "PUT,POST",
  remove = "DELETE"
}

One of the biggest things we changed about ColdBox 4.0 is making tons of the core completely modular.  To support this change, we needed to enhance our modules architecture which brought some cool new features to you.  

Module Inception

Every time I talk about ColdBox modules with people, I get asked if modules can contain modules, which up to now wasn't an option. But the first Module Enhancement I'd like to bring to your attention is just that.  We call it Module Inception.  This will allow for even greater ways for you to build and architect your applications.  Modules can be nested to the Nth degree.  Creating a ton of options and flexibility for you the developer in how you organize your code.

ColdBox has always provided nice, automatic error handling for your code.  Errors in your application are caught for you, and you can respond to them via convention-based methods, event handlers, or even interception points as you see fit.  (Read more on ColdBox error handling here)

If you do nothing, ColdBox will render a nicely formatted page with all the original exception information plus extra details about the ColdBox request which can be handy for debugging.  Due to our focus on security-by-default in ColdBox 4, we found that a large  number of people never change the default error template and their production servers give out way too much information!  Even though having a 'detailed' template by default was convenient, it wasn't secure.  

The new modular approach of ColdBox 4.0 means much of its built-in functionality has been moved to separate, installable modules. One of the many new modules introduced with ColdBox 4.0 is the Validation Module. To install, simply fire up CommandBox.

In ColdBox 4 we have expanded the runEvent() method to allow you to add caching parameters so ColdBox can take care of caching output from events.  This is a great way to accelerate the execution of widgets or viewlets within an application as it will execute them and cache them as needed.  Here is the new signature for the runEvent() method.

ColdBox 4.0 is the most significant change in the framework since it was first introduced. Go ahead - let that soak in a bit.

Now, what do I mean by that? Lots. Too much for a single blog post to do justice without becoming tl;dr. That's just how big these changes are.

Pruning

One of the key aspects to ColdBox 4.0 is what is not actually in...

ColdBox 4.0 has been built for speed.  We really wanted to improve performance out of the box.  We spent a lot of time making sure, as we always do, that we can squeeze everything out of the framework as possible.  

One of the major changes you should be aware of in terms of performance is that ColdBox handlers are now singletons out of the box. Most applications should be using their handlers as singletons because controllers generally shouldn't have state in an even...

In tandem with our ColdBox 4.0 release, we are publishing major releases of the core Box libraries as well:

CacheBox 2.0

Improvements

Read More
CacheBox, ColdBox MVC, LogBox, Releases, WireBox

We are very excited to announce the official release of ColdBox 4.0.  Work started a year ago with a very aggressive plan to overhaul the core and refocus the platform for agility, speed, and control.  We carved out tons of legacy support, leaving a slim and  fast M...

Ortus Solutions is proud to announce the general availability of ColdBox 4.0.0, WireBox 2.0.0, CacheBox 2.0.0 and LogBox 2.0.0.  This has been over 1 year of hard work from the engineering team to bring you some great upda...