RE: [coldbox:17848] [Coldbox 3.5.3] - Wirebox Question about OO models and how they get populated.

I’m not entirely sure what your company is expecting WireBox to do so I can’t address that too specifically, if someone thinks it’s magic pixy dust that creates everything for you, there mistaken. :slight_smile: That being said, WireBox is incredibly useful and I can’t imagine not using it. (We have 300 model CFCs between our Services, Beans, and DAOs)

Things WireBox can do for you:

  • It’s an object factory. I know Matt said it isn’t, and to some degree it might not fit everyone’s definition, but as far as a class responsible for abstracting the creation of objects, I’d say yes it fits that.

  • WireBox can create just about anything-- CFCs, java objects, web services. It can also create them based on the full component path, or by mapping IDs of your choice configured ahead of time in the config. You can explicitly configure the mappings or let Wirebox scan your model convention folders for you.

  • It’s an ioc container. Ioc stands for inversion of control which is basically a fancy word that means your code knows less and delegates to a framework that knows all the necessary details.

  • It is a DI engine. DI stands for Dependance Injection. If you have a User bean and it needs a reference to the userDAO, you could say the userDAO is a dependency of the user bean. WireBox is capable of creating each user bean with a reference to the userDAO automatically if you configure it to (or annotate the user bean to signify that it requires it)

  • It does setter injection (calling setter methods to set dependencies after creation)

  • It does constructor inject (passing dependencies into the object constructor upon creation)

  • It does mixin injection (Using small amounts of of pixy dust to inject references to dependencies directly into private scopes after creating objects.

  • It does persistence. This means you can specify an object to be persisted in any CF scope, as a singleton, or in any CacheBox provider. Then you forget about it and just ask WireBox for the object and it will take care of creating OR retrieving that object from its scope.

  • It does AOP. AOP stands for Aspect Oriented Programming and is too long to describe in a single bullet point. In short, imagine if you could configure an arbitrary chunk of code to execute before and/or after any method(s) in your entire code base without every actually touching those methods. This could let you enable, security, logging, or caching all across your application with just a few lines of configuration code.

  • There are a number of other things WireBox does, but these are the highlights.

Things Wirebox will not do for you:

  • Automatically write SQL for you
  • Automatically create services or beans or accessors/mutators for you
  • Automatically load composite objects outside of the dependencies you have autowired
  • Save or load data from the database into your objects
  • Automatically decide what classes should inherit from what other classes (it does have some cool virtual inheritance that you can configure yourself though)

Hopefully that helps put in perspective what you’d use WireBox for. Like I said, I can’t imagine NOT using WireBox. Most people don’t even touch half the stuff on my list above-- they just use WireBox to persist their singletons and inject references to their dependencies and honestly that alone is worth it. If you are wanting a framework to help with more, there are things like ORM that cover a lot of the bases in my second list and we can talk to you about what’s available for that.

> Also depending on what page you are reading so much of it seems out of date or you just get snippets, no offense entended.

Can you send us links to pages that look out of date or confusing? We’d love to fix them. As a rule of thumb, the latest version of the docs are all on and have a note at the top that says something like “Covers up to version 1.6” (that’s from the WireBox page).



ColdBox Platform Evangelist
Ortus Solutions, Corp

ColdBox Platform:

Well since you asked. Lets take the main wirebox page as an example. located here

Section : Advantages of a DI framework
Second bullet point: "By giving WireBox DI responsibilities, you will stop creating objects manually or using custom object factories.’

It sounds like to me, based on that, I will be able to stop using custom object factories. So how do I do that?

Looking a little bit further down the page I see. A primer to Wirebox injection. This is where I kind of feel like you only get part of the picture. The coffeshop example shows the different ways to do injection which is great. But object factories are more than just that. They are about pulling in all the resources to return to you an instance of a object. But the example never shows how that part would work with wirebox. It doesn’t really show you how you would stop using object factories as stated in bullet 2 up above.

After the short expresso example the page jumps to mockbox integration and then binders and mappings and more advanced stuff from there. I’m sure that is great for when you have been using wirebox for awhile and need to lookup what the different scopes are, but for a person trying to learn what wirebox is and how the way you are used to working with objects translates to it… it can be a little frustrating.

Now this page is great :

It does a great job of showing more of the components from start to finish and how they interact. I just wish that it showed some examples that didn’t use populateModel () (other than the ORM examples) and maybe another model with a little bit more complex structure. For example if Contact.cfc contained a PhoneNumber object. Where would the responsibilities lie for populating it and how does that work with Wirebox DI.

Anyway I’m not trying to nitpick, I like what I’ve seen of coldbox and wirebox. I’m just trying to figure out how it’s going to fit into my environment and how we are going to get the most from it.

It gets better