WireBox : Dependency Injection & AOP
7.x
7.x
  • Introduction
    • Contributing Guide
    • Release History
      • What's New With 7.2.0
      • What's New With 7.1.0
      • What's New With 7.0.0
    • Upgrading to WireBox 7
    • About This Book
      • Author
  • Getting Started
    • Overview
    • Installing WireBox
    • Getting Jiggy Wit It!
      • Instance Creations
      • Binder Introduction
      • Scoping
      • Eager Init
      • How WireBox Resolves Dependencies
    • Migrating From ColdSpring
  • Configuration
    • Configuring WireBox
      • Binder Configuration Properties
      • Binder Environment Properties
      • ColdBox Enhanced Binder
      • Types & Scopes
      • Data Configuration Settings
      • Programmatic Configuration
    • Mapping DSL
      • Mapping Initiators
      • Mapping Destinations
      • MapDirectory() Influence & Filters
      • Persistence DSL
      • Dependencies DSL
        • Mapping Extra Attributes
      • Mapping DSL Examples
      • Influence Instances at Runtime
      • Processing Mappings
    • Component Annotations
      • Persistence Annotations
      • CacheBox Annotations
    • Parent Object Definitions
  • Usage
    • WireBox Injector
      • Injector Constructor Arguments
      • Injection Idioms
      • Common Methods
    • Injection DSL
      • ColdBox Namespace
      • CacheBox Namespace
      • EntityService Namespace
      • Executor Namespace
      • Java Namespace
      • LogBox Namespace
      • Models Namespace
      • Provider Namespace
      • WireBox Namespace
    • WireBox Delegators
    • WireBox Event Model
      • WireBox Events
      • WireBox Listeners
        • ColdBox Mode Listener
        • Standalone Mode Listener
  • Advanced Topics
    • Child Injectors
    • Lazy Properties
    • Object Persistence & Thread Safety
    • ORM Entity Injection
    • Providers
      • Custom Providers
      • toProvider() closures
      • Virtual Provider Injection DSL
      • Virtual Provider Mapping
      • Virtual Provider Lookup Methods
      • Provider onMissingMethod Proxy
      • Scope Widening Injection
    • Property Observers
    • Runtime Mixins()
    • WireBox Object Populator
      • populateFromXML
      • populateFromQuery
      • populateFromStruct
      • populateFromQueryWithPrefix
      • populateFromJSON
    • Virtual Inheritance
  • Extending WireBox
    • Custom DSL
      • The DSL Builder Interface
      • Registering a Custom DSL
    • Custom Scopes
      • The Scope Interface
      • Scoping Process
      • Registering a Custom Scope
    • WireBox Injector Interface
  • Aspect Oriented Programming
    • AOP Intro
      • Overview
        • AOP Vocabulary
      • Activate The AOP Listener
      • Create Your Aspect
        • MethodInvocation Useful Methods
        • MethodLogger Aspect
      • Aspect Registration
      • Aspect Binding
      • Auto Aspect Binding
        • ClassMatcher Annotation DSL
        • MethodMatcher Annotation DSL
      • Included Aspects
        • CFTransaction
        • HibernateTransaction
        • MethodLogger
      • Summary
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Advanced Topics
  2. Providers

Custom Providers

If you need to abstract old legacy code or have funky construction processes, we would recommend you build your own provider objects. This means that you will create a component that implements wirebox.system.ioc.IProvider (one get() method) and then you can map it. Once mapped, you can use it anywhere WireBox listens for providers:

  • The Injection DSL →

property name="" inject="provider:{name or injectionDSL}";
  • The mapping DSL

map("MyCFC").toProvider('name or injectionDSL')

// or
setter,property,methodArg,initArg(name="",dsl="provider:{name or injectionDSL}");

Here is the interface you need to implement:

<cfinterface hint="The WireBox Provider Interface that follows the provider pattern">
    <---  get --->
    <cffunction name="get" output="false" access="public" returntype="any" hint="Get the provided object">
    </cffunction>
</cfinterface>

The CFC you build will need to be mapped so it can be retrieved by name and also so if it needs DI or any other WireBox funkiness, it can get it. So let's look at our FunkyEspressoProvider that we needed to create since we have some old legacy machines that we need to revamp:

component name="FunkyEspressoProvider" implements="coldbox.system.ioc.IProvider" singleton{

    property name="log" inject="logbox:logger:FunkyEspressoProvider";

    public function init(){ return this; }

    Espresso public function get(){
        // log
        log.canDebug(){ log.debug("Requested funky espresso"); }
        var espresso = createObject("component","old.legacy.Espresso").init();
        // add some sugar as the old legacy machine is not that great.
        espresso.addSugar(1);
        // returned provided object.
        return espresso;
    }

}

Finally we map to the provider using the .toProvider() mapping method in the binder so anytime somebody requests an Espresso we can get it from our funky provider. Please note that I also map the provider because it also has some DI needed.

component extends="coldbox.system.ioc.config.Binder"{
    function configure(){
        // map the provider first, so it can be constructed and DI performed on it.
        map("FunkyEspressoProvider")
            .to("model.legacy.FunkyEspressoProvider");

        // map espresso's to the old funky provider for construction and retrieval.
        map("Espresso")
            .toProvider("FunkyEspressoProvider");

    }
}

Cool! That's it, anytime you request an Espresso, WireBox will direct its construction to the provider you registered it with.

PreviousProvidersNexttoProvider() closures

Last updated 2 years ago

Was this helpful?