Question about Passing in Variables into a service/object

One way to do it is:

// Set the Start Row equal to 1 if not defined.
param name=“rc.StartRow” default=1 min=1;

// Setup the Defaults variables to blank
param name=“rc.firstName” default="";
param name=“rc.lastName” default="";
param name=“rc.emailAddress” default="";

// Setup a structure of the variables to pass in.
var params = {};
params.pFirstName = rc.firstName;
params.pLastName = rc.lastName;
params.pEmailAddress = rc.emailAddress;
params.pSortby = “lastname”;

// Instantiate the object manage account service
var oAccount = populateModel(“accountService”);
// Get the accounts
rc.qManageAccount = oAccount.getAccounts(argumentCollection=params);

Another way to do it is:

// Update the personal address
var oAccount = populateModel(“accountService”);
rc.qAccount = oAccount.getAccounts(pUserID=rc.userID, event=event);

Is there any reason NOT to just pass in the event and then when you get to the object pull out the items you want to use?

Is there any reason NOT to just pass in the event and then when you get to the object pull out the items you want to use?

Not at all, in fact I have done this with a lot of my applications now. But it wont suit all situations, so I ended up with a few duplicate methods like




Both do the exact same thing, the only difference is one is by the information passed by the event structure and the other is a wrapper to the former.

I found this so much quicker in getting something done, and a lot less code in my handlers.

I can think of a couple, but I think it boils down to preference. (Although there’s probably a few who would fight tooth and nail against it)

I understand that the event object is technically “model” as far as the framework is concerned, but I still consider it part of the controller portion of your MVC to an extent since it’s dealing with the request collection, layouts and views and contains behaviors to route your request. I don’t feel comfortable mixing the request context with my apps model (services and such). I feel it is more appropriate to have the handler pull out the necessary information from the request collection and pass that into the service calls.

One reason for this is the API for your service call is pretty watered down when it simply accepts a generic object and then is expected to know things about the naming of variables coming from FORM and URL. It would be difficult for another programmer to look at that call and reasonable know what it expects.

Some also say that your model should be able to switch from one framework to another with no dependencies, though I’m not quite as sold on that one. What I can agree to though,is that your service calls may need to be called at some point outside of a standard ColdBox request, or for that matter, within another model-layer call where the event object doesn’t exist. I would rather the model simply accept in what it needs as separate arguments.



Well kind of. I’m new to ColdBox but not to frameworks nor CF. CB is just amazing but like other frameworks, I have some issues with the black box approach to handling global models or more to the point, global payload. I think in defense of any framework conceptually, if you are going to accept things like AOP, IoC or even just a simple concept like plugins, we have to also accept that things cannot be as strongly typed or as verbose as we might like. I am the developer people hate when I have 20 parameters in a method signature and not one of them is under 5 syllables…but like you suggest, I want to be able to leave behind a piece of code that the next developer won’t have any questions about. I think at a high level here, there is a tradeoff I have to be willing to accept as part of the huge advantage CB (and others) offers.

I just wanted to chime in my 2-3 cents because I liked the perspective. I’m a CB noob so feel free to just chortle and ignore me :slight_smile:


Everyone has made good points.

I use long argument names like Mike that tend to be very descriptive, and, I choose to develop a model layer that is very separate from the framework. I almost always use named arguments. In six months, I appreciate the extra effort as I run the application in my mind during maintenance.

The only thing I would add to your second approach is a THIS or VARIABLES scope property called IMPORTS. You can grab the list of “import” properties during populateModel(model=x,include=y) so you avoid allowing users to add params that you need to be publicly settable for you application, but, they have not business passing without your knowledge. An example of a good use case is a public property called “deleted” common to many applications. If a user added ?deleted=1 to the URL it could cause some nasty issues for your app.

Hope that helps?

Aaron Greenlee