Blog

The best part about open source projects is you! Many hands make light work and at Ortus we love getting input from the many smart community members out there.  The first way you can help is to report bugs or enhancements in our ticket tracking system.  You can read our guide for that here:

http://blog.coldbox.org/blog/how-to-create-a-jira-account-and-enter-coldbox-tickets

The second thing you can do is to actually submit fixes yourself!  This may seem scary, but it's a pretty straight forward process once you've done it once.  We can never have too many people willing to help. Let's jump in and cover the steps it takes to submit some code to the ColdBox Platform.

The best part about open source projects is you! Many hands make light work and at Ortus we love getting input from the many smart community members out there.  The first way you can help is to report bugs or enhancements in our ticket tracking system.  You can read our guide for that here:

http://blog.coldbox.org/blog/how-to-create-a-jira-account-and-enter-coldbox-tickets

The second thing you can do is to actually submit fixes yourself!  This may seem scary, but it's a pretty straight forward process once you've done it once.  We can never have too many people willing to help. Let's jump in and cover the steps it takes to submit some code to the ColdBox Platform.

Error handling is one of those important things that many developers neglect.  Your code never errors once you're done testing it, right :) ColdFusion's detailed error messages were always a draw to the platform, but have become a bit of an embarrassment when surfing across a site that's sporting the defau...

ColdBox Plugins have graduated to become just models. The plugins convention has been removed and all references to plugin injection or DSL's are gone. You must now place all your plugins in your models directory and request them via getInstance() or getModel() calls.

Plugins are an old ColdBox convention but their baggage doesn't really serve a purpose now that we have modules for easy packaging of libraries and WireBox for easy creation of CFCs. Neither of those existed back when Plugins were birthed. It's time to say goodbye to the concept of plugins, but all their functionality will still be here, just with a slightly different (and more standardized) way of creating them.

If you have a ColdBox config setting UDFLibraryFile, then you'll want to change it when upgrading to ColdBox 4.0. It functions the same, but is now called applicationHelper.

applicationHelper is an optional setting where you can declare the path to a UDF template to load for usage in the views, layouts and event handlers. You can use relative paths to your application's root or ColdFusion mappings.

For example if I have my udf templat...

With the advent of so much more functionality in modules, in ColdBox 4 we added the ability to group modules in a single directory we lovingly call The Module Bundle.  This feature became a reality due to a real client's need of being able to logically separate modules into logical buckets.  His application had an extensive amount of modules and he wanted to further segregate them, thus module bundles became a reality.  

If you have been following our series here on ColdBox 4.0, you are probably sensing a theme.  

Another major change in ColdBox 4.0 was the removal of plugins as a thing.  They were just model objects anyway and we had treated them as such within the framework for some time.   However, because of that, we needed to do something with some of our various "core" plugins.  So sticking with our...

ColdBox 4.0 is a major release for the ColdBox line. The most major since its original release in June 2006. To boost efficency and open up options, we've removed a lot of non-necessary items from the core installation and made them available through modular architecture instead. However, there are some thing that we've kept - and for good reason. This post discusses what we kept in the core of ColdBox 4.0 and why.

Welcome to the jungle

Remember a time when the internet was a safe place. Where your email wasn't getting hacked every 3 months, nobody wanted to XSS something malicious to you or through you, and no one conceived of encrypting your hard drive for money?

I don't either. Since its inception, the internet has been a jungle of security complications.

CSRF: not the good kind of surfi...

ColdBox allows you to store the details of your CF datasources in your configuration file.  This prevents you from needing to store usernames and passwords in  your actual code, and allows you  to easily switch an application to another database, even with the environment control.  In  the past this datasource information was presented to you as a CFC object with getter methods.  

In ColdBox 4.0 we recognized that the datasource bean was really just a value object with no behaviors-- only data.  In the spirit of simplification,  we've replaced the datasource bean with a standard struct of data.