- preHandler
- pre{Action}
- postHandler
- post{Action}
- aroundHandler
- around{Action}
The methods in your handlers (actions) have always accepted the "event" object, which is the request context for that event and contains things like the request collection and private request collection.
Trying to decide whether to use ColdFusion's EHCache implemention or CacheBox? You don't have to choose one or the other! CacheBox is a cache aggregator, which means it lets you use the same standard API to interact with any number of different cache providers-- including EHCache.
Everyone should be familiar with the setView method in the event object which is used for a handler's action to tell the framework which view file should be used to render the event:
event.setView(view="general/index");
What you may not realize is that calling setView() is optional. If you don't explicitly set a view file, ColdBox will then look for the view according to the executing event's syntax.
Many of you using models in your ColdBox app are familiar with how easy WireBox makes it to use the Singleton Pattern for components that are only created once in the life of your app.
This can also be a bit of a pain when you are working on the code inside your singleton objects. Any changes require you to re-create the singleton object which typically involves a reinit of the framework. ColdBox has a handy setting for you to use on your development environment called singletonReload.
Just a quick announcement that we now have finally implemented a validation engine and aggregator in ColdBox for 3.5 release. And in true professional open source style, fully documented: http://wiki.coldbox.org/wiki/Validation.cfm. It has an embedded validation engine but it also allows you to use ANY validation framework within ANY ColdBox application as long as it satisfies a few interfaces. Check out our documentation page but here is a little teaser: