[wirebox-2.0.0] Binder parent injecting mixins into an existing object

I’m likely to botch this question so be patient-ish.

I’m using a secondary binder (parented to a “master” binder)…which is working simply great. But now I have a weird situation. In the second binder, I have a need to take an existing scopes.request object created in the first binder and extend it so that to the second binder, it “looks” like the same object but now has additional methods associated with it (attempting through mixins) relevant to the nature of the child binder.

This of it this way…(not using coldbox for this project, but pretend with me). In a module, I want to grab a user object from the main application and within that module, extend the user object to provide easy syntax to other methdologies that only the modules cares about. I could easily write a service object and pass it the main applications variable, yada yada…I mean really there are several ways I suppose this could “easily” be handled…but this is what I would like to do:

Imagine in my main application binder I have delcared:


later the module is loaded and ULTIMATELY (say it’s a module for managing a persons list of pysicians)…somewhere in the interfaces in the modules, You might stumble across:

arrayofdocs = CurrentPatient.GetListOfPhysicians();

CurrentPatient IS CurrentUser ++ so in the module mappings for wb, I have tried things like:


this does not break anything…CurrentPatient is equal to the CurrentUser as far as I can tell, but none of the mixins are in the object…so likely they are not actually equal…just not sure.


and that was just an epic fail so is likely not even the right track. Another though was to create my own “CurrentPaitent” object of the same type and just do some “cloning” methodology to get the property payload over…but that kinds feels dirty.

Does anyone have any helpful thoughts on whether there is a way to do what I’m suggesting here or should I just abandon hope and follow a more obivous path?

Thanks for any insight.


I am not sure what you’re trying to achieve, but wouldn’t GetListOfPhysicians() be a service. For example

inject name=“Physicians”;

function someFunction() {

Seems that the approach you’re trying is lengthy and complicated for no reason.

Yeah, I don’t entirely disagree…but I also want what I want. I really want to know if it is possible to “extend” and object already in existence based on a secondary binder’s access to it. I’ve already got the service to do the work and my bean-like example was just illustrative…the original class is more of a service and created, in essence, in another application where the module wants to capitalize on that and syntactically make the “extension” appear seamless.

Anyone else have an opinion to share?

Not sure I am really following what you’re trying to achieve, but why don’t you intercept on the instanceCreation (can’t recall the AOP off the top of my head), check to see if the conditions match and load your new one or do what you have to do. The downside is you will be creating / recreating objects, which kind of defeats the purpose of having them cached.

Now that is an original approach I had not considered…but now that’s too complicated :slight_smile:

Let’s try a more generalized approach…remembering I am NOT in a coldbox environment for this project…wirebox only…but I’ll use CB as my framework metaphor because in many ways, this application is a “homespun” version of CB from long long ago in a galaxy far far away.

My application has a User
My application shall share that user among it’s various modules
In a given module, I might have more “user” information than what the other modules might have or need to see
In some way, I want to create a “mimic” object of the user whenever I’m playing around in a module that is the same in everyway (properties and methods) but that provides added functionality.

In the “main” application
CurrentUser.getMyProviders() does not exist because the main application does not want to provide that information…the “native” user object does NOT have that method.

In the “providers” modules
CurrentApplicationUser.getMyProviders() DOES exist…well because it is technically a different object. It has all the payload of CurrentUser plus all the additional properties and methods of that modules “CurrentApplicationUser”.

So, in and of itself that is not too tricky. I can pass CurrentUser into a property of CurrentApplicationUser and just use the accessor:


but now in development, I always have to remember that in my module, the “current user information” is buried in a property of my modules COPY of CurrentUser…which I don’t like. I would rather


But I want to do this with the binder the module so wirebox can “create” CurrentApplicationUser by inheriting the existing object “CurrentUser”. Thus, because of the modules nature of “CurrentApplicationUser”, I could achieve both syntaxes I want


where in another module, doing the same thing, CurrentApplicationUser the class is designed differently and would not have a getMyProviders() method.

Positively I can do this with some service and decouple getMyProviders() completely by sending CurrentUser to some service method and returning the providers.
Positively I can achieve this EXACT syntax if I create facade methods in CurrentApplicationUser that all point to the contents of this.getCurrentUser() (this was the easiest and how I’m doing this now)

…but do I have to…can wirebox help me map CurrentApplicationUser to the instance of CurrentUser already created (like a parent though that did not work or like virtualinheritence but that did not work…it seems in these cases, when the parent for the secondary binder is set effects how parent and virutalinheritance see the mappings that are available at the time they are loaded)? And more importantly, do it in a second binder that is slaved (parented) to the main application binder?

We can drop this if it seems a study in futility…I was able to achieve what I wanted in another way before I even started the thread. I just wanted a better way that made more sense to me and more importantly made it easier on other developers later down the road but not mucking with the “users” object syntax.

We can drop this if it seems a study in futility...I was able to achieve
what I wanted in another way before I even started the thread. I just
wanted a better way that made more sense to me and more importantly made it
easier on other developers later down the road but not mucking with the
"users" object syntax.

To be frank, I will go back to my original statement, it sounds like you're
over complicating it. I won't pretend to understand fully why you won't
decouple things here and really make the next wave of developers life easy.
After all isn't that your goal!

But having said that, I haven't though long and hard here. But could you do
a factory pattern here with the wirebox object, that could return the right
object required?

Andrew Scott
WebSite: http://www.andyscott.id.au/
Google+: http://plus.google.com/113032480415921517411

Remember that there are several roads one can take to making another developers life easier and it is in my humble opinion, given the environment, the number of developers, the project and my experience, this WAS going to be the easy thing.

I appreciate you sticking with me Andrew…you do always present a challenge to my thinking. And you are right, some things can easily get overcomplicated. I do not necessarily share that opinion in this case because I believe wirebox / coldbox are MEANT to do the complicated things if we so wish it…to make the things outside the framework easier. But I’ve wasted enough of both are time trying to suss out “something”. Glad you hung in there with me.


lol, I guess my problem was trying to work out exactly what you are trying to do. You maybe right, it could be down the track with what you’re thinking. Just I am not sure I understand the problem enough.

LOL…and ironically…you showed me that maybe I don’t either !


Forgive me if I’m missing something obvious, but is there a reason why you don’t just extend the base user with your specialized user? When you talk about having more specific user with additional properties and methods it seems like what you’re looking for.

component {
property name=“name”;

component extends=“user” {
property name=“specialProp”;

If there is a technical reason why you can’t do actual inheritance, have you looked into WireBox’s virtual inheritance?



ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com