trying again (with a different Q) to post. Last posting must of not
been successful...
what would be best practice to store my data access layer in the
application scope in Coldbox? I'm using DataMgr as my DAL and I'd like
to be able to store it in the application scope on AppInit via the
applicationStorage plugin...
You can use that approach or you can use the ColdBox cache. The difference, is that if you place the object in the coldbox cache, with a timeout of 0 = singleton, then you can autowire elements from the cache into your handlers, model objects, plugins and much more. This will in turn, make it easier for you to use the object in question (DataMgr) anywhere in the lifecycle of the application. So my suggestion to you, is to use the cache.
Example:
var DataMGR = createobject(“component”, … );
//cache it
getColdboxOCM().set(“DataMgr”, DataMGR, 0);
Ok, the idea is to use the application start handler to configure your application once it starts up.
So do the following.
Open your coldbox.xml.cfm and look for the setting “ApplicationStartHandler” and map it to the event “main.onAppStart” or whatever naming convention you would like.
Create the event in the handler you choose. Example: main.onAppStart. That method should already be created by the application template. Then inside of that method is where you would create any necessary objects, libraries, etc that your application needs once it starts up. So the best practice is to create everything you need in this event and cache it. Then you application is ready for using it.
thanks much Luis. That's what I had initially did with loading my DAL
into the application scope... Until I ran into the problem of my
plugin not being able to access my object... Is this a mistake on my
end? should all custom plugins have access to the application scope?
When I tried it failed...
But as you said cache-ing it, I will have scope in my plugin...
I appreciate your help... one more thing though... as I've been
working with Coldbox this last week or so... What's the difference
between the variables scope in a CFC and the "instance" scope?
This is a very good question. The variables scope is the default private scope for cfc’s. However, ColdFusion also stores the private methods here. So a good best practice is to create an instance variable (structure) that holds an object’s data. The benefits are the following:
Separation of a class’ instance data and its data members (methods)
A very easy way to get an object’s internal state by just dumping the instance scope
A very easy way to populate the instance scope with data.
As you can see, due to the nature of ColdFusion storing functions in the variables scope, creating a virtual instance scope gives you the added separation needed between data and functions.
K, Im trying to test a service object of mine and when I try to
autowire my DAL into a model object, it's not seeing it. from my
handler Im using the good ol way of createObject to instantiate my
model... is this a problem? should I be doing this another way... all
Im doing is testing a method. is my object from cache not getting to
my model for some reason?
eg.
HANDLER:
<cfset user = createObject("component", "baseApp.model.UserService") /
Of course, you are creating the object, not ColdBox. The whole point of integration is that you don’t have to create and configure the objects anymore. Just use the getModel() methods.