coldbox plugin dependency

Hi all,

3 weeks ago i started using coldbox, and i really like the framework,
because of its intereceptors, and pre-made things like security
intereceptors and all its plugins. And especially the documentation is
what made be adopt the framework.

The only thing i have some second thoughts with, is the plugin system.

I think the plugin system is completely fine, if the plugin is really
extendin the coldbox functionality. With this i mean, that the plugin
uses core coldbox functionality like the request collection for
example. The beanfactory seems to be (partly, for example the
populateBean method) a good example of this althought the generic
populateBeanFromStruct does not have any dependency with the coldbox

There are also plugins in the coldbox framework, like queryhelper or
the utilities plugin, that on first glance do do not need any depency
with the coldbox framework. The problem is, they are a plugin, so they
are extending a base plugin class... and also coldbox will inject
methods in these plugins (am i right?).

If i am making for example an object in my model, or another utility
object (or maybe a cfc that represents a general widget to, for
example, generate a form), and i want to use some plugin methods (like
the queryhelper), i will make my model or the utility object dependent
on the coldbox framework. If i for example want to use another
framework or no framework, i cannot re-use these model objects or
utility objects.

So the problem i have with the plugin system, is that it seems to make
needless dependencies for certain plugins.

A solution for this, would be to have in addition to the plugin
folder, a util folder. In which framework-independent utility objects
can be located, packages with coldbox juts as an extra. Coldbox could
provide a getUtil method, to make it easier to instantiate these

What dou you guys think about this? Am i missing something?

Klaas-Jan Winkel
freelance developer

Note: instead of cfc i always say object, this feels more natural to

Totally understandable. However, the idea for the plugins, is for them to be tightly integrated to the framework, they are part of it. They where built to take advantage of what ColdBox offers, if not, I would be recreating the wheel for each library I create.

For your functionality, I believe creating your own libraries is the way to go, then just bring them in via IOC. This way your dependencies are controlled by you.


Ok, i understand, so then you would probably recommend not to use
these plugins in the model, right? (so they are made for use in
intereceptors, event handlers etc.)


Well, it all depends on you. I use them in my model all the time. At the end of the day, if you ever move away from ColdBox (why?? :slight_smile: ) You can still replicate your dependencies with ease.

Again, it is up to you, however, decoupling yourself completely from something is a Utopia. You will always have a certain extend of dependency on something.


How could i replicate dependencies then?

Example: Look at the session storage plugin, it is a very nice session facade object. You could easily clean that up to be used without any coldbox dependencies. But it would be then your responsibility to instantiate and configure this library.


I also, forgot to mention, that you DO NOT have to have the inheritance on coldbox.system.plugins if you want to. If you so desire not to do inheritance you can. The only requirements is that you persist the incoming controller argument and use it to talk to the framework if needed. So basically, your init() method must take in an argument of controller. You can then use it or ignore it. That is up to you. This way, you are only coupled to a constructor method interface, rather than inheritance.

However, if you so wish to use the controller composition, then you can. You basically switch from inheritance to plain old composition.