Blog

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...

Here is a short introductory video of how you can start protecting your ColdBox applications with our FuseGuard Module!  Enjoy!

REST APIs are a popular and easy way to add HTTP endpoints to your web applications to act as web services for third parties or even other internal systems. REST is simpler and requires less verbosity and overhead than other protocols such as SOAP or XML-RPC. Creating a fully-featured REST API is easy with the ColdBox Platform. Everything you need for creating routes, massaging data, and enforcing security comes out of the box.

The ColdBox MVC Platform has had excellent support for ...

LogBox ships with a number of appenders for you to use including the File, Email, and Socket Appenders. These all have a default way that they format the data before its persisted. For instance, the FileAppender will write out each log event like so:

"Severity","Name","MM/DD/YYYY","HH:MM:SS","Category","Message"

If you need the data to be in a different format, or perhaps e...

We try not to break backwards compatibility in the ColdBox framework, but sometimes there's a compelling reason to do so.  In the notes for the 3.8 release you may have seen [COLDBOX-218] - Default reinit and debug hashed passwords.

Taking a cue from recent breaches on the Internet, we're focusing on making things more "secure by default".  Th...

If you haven't heard, the latest addition to the *Box family is TestBox and is currently out in Alpha. It allows for the standard xUnit style of testing that you may already be familiar with in tools like MXUnit. TestBox also allows for a newer style of testing known as Behavior-Driven Development or BDD. BDD helps focus on writing tests that confirm specific business needs are met by your software and typically use some sort of human-readable DSL that allows the test to be self-documenting a...