(ColdBox-4.0) Overriding core objects

In ColdBox 3.x we were able to use the “coldboxExtensionsLocation” setting to override core plugins without actually touching any ColdBox files. Does CB 4.0 offer anything similar to this for some of its core objects? In particular, I want to use my own customized version of the HTMLHelper. (I know I can simply replace coldbox.system.core.dynamic.HTMLHelper with my version, but I was hoping to avoid that so that upgrading to future versions of CB will be easier)

Hi Ben,

For this 4.0 update, plugins do not longer exist.

The HTML Helper is mapped as a alias/path to coldbox.system.core.dynamic.HTMLHelper which you can alter via WireBox to point it to another location or modify the mapping.

This is still new to us as well, so input is welcomed.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
P/F: 1-888-557-8057
Direct: (909) 248-3408

ColdBox Platform: http://www.coldbox.org

ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483

Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox

Good question Ben. It doesn’t look like Luis added any information about the HTMLHelper plugin to the docs, but looking at the code, he just moved it to coldbox.system.core.dynamic and turned it into a regular-old model.

If you have a custom CFC you’d like to use and you’re creating it yourself, just ask WireBox to create your CFC instead.

HTMLHelper = getInstance( ‘myCustomHTMLHelper’ );

There are only two places in the core that reference the HTMLHelper. One is the html variable in the renderer that is made available to your views/layouts. The other is the addAsset() method in the frameworkSuperType which is made available to handlers, views, layouts, interceptors, etc. Both of those places use WireBox, but they are hard-coded to the path coldbox.system.core.dynamic.HTMLHelper which isn’t very useful. I’m not sure why Luis didn’t create a mapping, or even put it in a module. I think this would be great for a core module convention that ships with the framework, but we’ll have to let Luis chime in on what he’s done here and how to extend it.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Yes, this is hard coded at the moment until we find a more flexible way. The core of the release was extensive, so there are still bits and parts that need to be fine-tuned.

Luis Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
P/F: 1-888-557-8057
Direct: (909) 248-3408

ColdBox Platform: http://www.coldbox.org

ContentBox Platform: http://www.gocontentbox.org
Linked In: http://www.linkedin.com/pub/3/731/483

Social: twitter.com/ortussolutions | twitter.com/coldbox | twitter.com/lmajano | twitter.com/gocontentbox

I would recommend minimally creating a mapping in WireBox with “short name” for the HTML instead of the full path. People will be able to register their own mapping to override that.

Additionally, I think HTMLHelper would be a good candidate for a module. Then, the mapping will get auto-created. It will also be upgradable separately and will be easier to override. Implementing the core module convention discussed in COLDBOX-250 would make it easy to still ship the HTMLHelper with ColdBox if we wanted.

We also need to update the compat docs to cover all the plugins that were present in 3.x.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Yes, making the HTMLHelper a module would be great. But in the mean time, I followed Luis’s advice and used wirebox to alter the path, “coldbox.system.core.dynamic.HTMLHelper”, and make it point to another location. Like so:

binder.map(“coldbox.system.core.dynamic.HTMLHelper”).to(“MyCustomHTMLHelperLocation”);
binder.map("HTMLHelper@myModule).to(“MyCustomHTMLHelperLocation”);

The first mapping makes the FrameWorkSuperType and Renderer both point to my version. The second mapping is so I can easily inject it in other parts of my code. This appears to be working. I’ll post here if I find any problems for some reason.

Thanks to both Brad and Luis for the fast responses

p.s. I am in the middle of upgrading my existing application to 4.0, and I am really loving it so far. Way to go!