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
  • Scope Annotations
  • Scope Configuration Binder
  • Internal Scopes

Was this helpful?

Edit on GitHub
Export as PDF
  1. Getting Started
  2. Getting Jiggy Wit It!

Scoping

PreviousBinder IntroductionNextEager Init

Last updated 2 years ago

Was this helpful?

We touched briefly on singleton and no scope objects in this section, so let's delve a little into what scoping is. WireBox's default behavior is to create a new instance of an object each time you request it via creation or injection (Transient/Prototype objects), this is the NO SCOPE scope.

Scopes allow you to customize the object's life span and duration. The singleton scope allows for the creation of only one instance of an object that will live for the entire life span of the injector. WireBox ships with several different life span scopes but you can also create your own custom scopes (). You can also tell WireBox in what scope to place the instance into by annotations or via the configuration binder. We have an entire section dedicated to discovering all the WireBox annotations, but let's get a sneak peek at them and also how to do it via our mapping DSL.

Scope Annotations

  • You can tag a cfcomponent tag or component declaration with a scope={named scope} annotation that tells WireBox what scope to use

  • You can have nothing on the cfcomponent tag or component declaration which denotes the NO SCOPE

  • You can tag a cfcomponent tag or component declaration with a singleton annotation

Scope Configuration Binder

component extends="wirebox.system.ioc.config.Binder"{

    function configure(){

        // map with shorthand or full scope notation
        mapPath("model.CoffeeShop").asSingleton();
        mapPath("model.CoffeeShop").into(this.SCOPES.SINGLETON);

        // map some long espresso into request scope
        map("longEspress")
            .to("model.Espresso")
            .into(this.SCOPES.REQUEST);

        // cache some tea
        map("GreenTea")
            .to("model.Tea")
            .inCacheBox(timeout=20,provider="ehCache");

        // cache some google news that refresh themselves every 40 minutes or after 20 minutes of inactivity
        map("latestNews")
            .inCacheBox(timeout=40,lastAccessTimeout=20,provider="ehCache");
            .toRSS("http://news.google.com/news?output=rss")
    }

}

Internal Scopes

Here are the internal scopes that ship with WireBox:

Scope

Description

NOSCOPE

A prototype object that gets created every time it is requested.

PROTOTYPE

A prototype object that gets created every time it is requested.

SINGLETON

Only one instance of the object exists

SESSION

The object will exist in the session scope

APPLICATION

The object will exist in the application scope

REQUEST

The object will exist in the request scope

SERVER

The object will exist in the server scope

CACHEBOX

This is cool! We can now have full control of how objects are persisted via the WireBox injector, we are not constricted to one type of persistence anymore.

Caution If you use a persistence scope that expires after time like session, request, cachebox, etc, you will experience a side effect called scope widening injection. WireBox offers a solution to this side effect via WireBox Providers, which we will cover in detail.

A object will be time persisted in any cache provider

please see the custom scopes section
CacheBox