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.
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...
If you've ever worked with jars or raw java in ColdFusion, you will love the JavaLoader module for ColdBox. The JavaLoader module will interface with Mark Mandel's JavaLoader to allow you to do a network class loader, compiler and proxy. You can keep jars with your application's code instead of putting them in ColdFusion classpath, and you can even dynamically compile java co...
Looking to secure your ColdBox application? The Security Module can be your security rules engine for your application. It provides flexible options to rules based security for you to use.
We have often talked about how a module can be either complex or as simple as an interceptor. Our Security Module is basically just an interceptor that gets registered in your application to enforce rules you define. Installing it is easy u...
You may be wondering where all that amazing debugging information went in your ColdBox 4.0 application. Have no fear. You can still have your cake and eat it too. We modularized it (sensing a theme in ColdBox 4.0 yet?) So, how do you get all that wonderful debugging info?
Easy! Using CommandBox, run the following command.
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.
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.
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.
ColdBox 4.0 is now in Release Candidate and we're tightening down all the screws for the big release. As 4.0 is a major release of the platform, we've taken the opportunity to really clean up the code, making changes and improvements where necessary. This i...