Blog

ColdBox 4.0 Removed Plugins

Brad Wood February 26, 2015

Spread the word

Brad Wood

February 26, 2015

Spread the word


Share your thoughts

ColdBox Plugins have graduated to become just models. The plugins convention has been removed and all WireBox references to plugin injection or DSL's are gone. You now just 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.

// old
getPlugin("MyPlugin")
property name="foobar" inject="coldbox:plugin:foobar";
property name="foobar" inject="coldbox:myPlugin:foobar";

// new
getInstance( "foobar@myModule" );
property name="foobar" inject="foobar@myModule";

You'll notice ColdBox used to make a differentiation between core plugins and custom plugins.   There is no such difference now.  A couple plugins that got baked into ColdBox as model such as the HTMLHelper and XMLConverter plugins are now simply called HTMLHelper@coldbox and xmlConverter@coldbox.  All the rest of the plugins that were shipped off into modules are simply namespaced by the module name which is the standard model convention for modules.

  • sessionStorage@cbstorages
  • ValidationManager@cbvalidation
  • messagebox@cbmessagebox
  • i18n@cbi18n
  • QueryHelper@cbcommons
  • etc...

If a model isn't defined, check and make sure you have installed the module and reinitted.  When you install modules via CommandBox, you can use the handy list command to check and see.

CommandBox> list
Dependency Hierarchy myApp (1.0.0)
├── coldbox-be (4.0.0)
└─┬ cbvalidation (1.0.0)
  └── cbi18n (1.0.0)

Plugin Base Class

With the removal of plugins, coldbox.system.Plugin no longer exists. If have custom-written plugins that used some of the convenience variables such as controller, logbox, or wirebox that came from this base class, you'll need to inject them using the appropriate injection DSL. If you were using any of the convenience methods such as getRequestContext() or getRequestCollection() should be delegated to the appropriate service or the ColdBox controller.  (The request context can be obtained from the RequestService)

Any variables or methods related to instance.pluginName, instance.pluginVersion, etc serve no purpose now and can be removed from the code.

Sharing Code

So now that plugins are no more,  you have two main options for sharing a bit of code with other developers that you want them to be able to easily drop in and use.

  1. Put on ForgeBox as a model.   This works well for very small stand-alone pieces of functionality that don't need a load/unload lifecycle and don't depend on anything else.
  2. Put on ForgeBox as a module.  Modules can be very simple, but also can allow for multiple models, configuration, a load/unload lifecycle, and other dependencies.  This is the recommended approach for any bit of code you want to share since it's the most flexible.

Add Your Comment

Recent Entries

Protect Your Data with Proactive Database Security Management

Protect Your Data with Proactive Database Security Management

In today’s digital age, data is among the most valuable assets for businesses. It powers decision-making, customer engagement, and operational efficiency. However, as data volumes grow, so do the risks associated with managing it. Ensuring database security and compliance is no longer optional—it’s a necessity.


The Evolving Landscape of Database Security

Modern databases face a myriad of challenges, from increasingly sophisticated cyber threats to strin...

Cristobal Escobar
Cristobal Escobar
December 06, 2024
The Experts Driving BoxLang: The Team Behind the Revolution

The Experts Driving BoxLang: The Team Behind the Revolution

Introduction

BoxLang is not just another programming language; it’s a revolutionary step forward for JVM environments. But who are the minds behind this innovation? Meet the talented team of architects, developers, and engineers who have combined decades of experience to create BoxLang—a language built for scalability, performance, and efficiency. Let’s explore their ex...

Cristobal Escobar
Cristobal Escobar
December 04, 2024
Why BoxLang is the Modern Software Development Evolution You’ve Been Waiting For?

Why BoxLang is the Modern Software Development Evolution You’ve Been Waiting For?

In today’s software landscape, developers need tools that deliver flexibility, efficiency, and modernization. With decades of open-source expertise, Ortus Solutions introduces BoxLang—our most ambitious project yet. Built for the JVM, BoxLang integrates seamlessly with Java, offering powerful features for scalable, high-performance web applications. Fully compatible with CFML, it ensures a smooth transition and expanded capabilities for existing projects.

Maria Jose Herrera
Maria Jose Herrera
December 04, 2024