I was working more with Coldfusion 9 ORM and found another small caveat I thought I would share.  When working with a relationship that is filtered, the implicit "has[property]", the has does not take into account the filter.  The implicit get works as expected however.  Consider the following persistent cfc...

Read more...

We did a hands on workshop at our Inland Empire User group yesterday in Pomona, California.  We had fun installing CF9, Adobe CF Builder and ColdBox 3 Beta.  We managed to build a simple task manager with all the new nice ORM features and coldbox 3.0.0 features.  So if you are interested in seeing the workshop online, here is the recording: http://adobechats.adobe.acrobat.com/p79504808/.

If you would like to download the workshop assets, go to our IECFUG resources page to download it.

I have been asked quite a few times why not make a ColdBox lite version where you can only have the basics?  Well, not many people now that this already exists.  Therefore, I am linking to the SimpleMVC template you can use if you are just starting with ColdBox.  This template is just the basic ColdBox conventions and a few settings, that's it. This template will ease you in to ColdBox MVC development.  Once you are comfortable with just the basics of how to build apps with conventions you can always add on and start brining in extra features from the Coldbox Platform like: caching, logging, AOP, interceptors, feed integrations, security, etc.  However, you won't feel as intimidated as if you where starting with a huge settings file.

The reason of having all the settings listed out is to tell the developer that there are all these settings you can use.  It is also hard to create templates when everybody's level and approach is different.  However, this can be overwhelming to entry level users, therefore we are now including the SimpleMVC template in the coldbox downloads to come or you can download it from here now: http://www.coldbox.org/downloads/simpleMVC.zip (3.0 template)

So let's do a simple ColdBox for Newbies guide:

Read more...

One of the nice things about ColdBox's model integration features are the ability to inject objects by using annotations via the cfproperty tag.  This gives a cleaner API to objects that don't really need to expose setters just for dependency injection purposes.  Why? well, in MY opinion, objects should be shy and only expose what they need to expose to the outside world.  By leveraging annotations, I can cleanly define the dependencies of my object and what is even better, it can even be self-documenting because they are cfproperties.  Not only that, since ColdFusion is a dynamic language and NOT JAVA, we can leverage much more than traditional setter/constructor dependency injection. In our next release, 3.0.0, we will expose our model integration features as a new dependency injection (IoC) framework which we are tentatively naming BlenderBox.  More about BlenderBox in other posts. So now that we introduced that ColdBox can blend your object's with other objects via annotations, how do we test them?  We have no setters or constructor arguments to inject them.  Well, but we do have mxunit and MockBox, which make our lives simpler and HAPPY!! So let's look at a simple service I am currently developing: <cfcomponent name="BetaTransferService" output="false" extends="beta2007.beta94.model.baseobjects.BaseService" hint="The main beta transferring service">

<!--- Dependencies -->
<cfproperty name="betadao" type="model" scope="instance">
<cfproperty name="configBean" type="model" scope="instance">

ALL OTHER METHODS HERE

<!--- onDIComplete -->
<cffunction name="onDIComplete" access="public" returntype="void" output="false" hint="Called after wiring is done">
<cfscript>
/* Setup Configurations */
var config = instance.configBean;

setProgramID(config.getKey('programID'));
setDefaultPublicRole(config.getKey('DefaultPublicRole'));

/* Get the program record */
instance.programRecord = instance.betadao.getProgramRecord(getProgramID());
</cfscript>
</cffunction> As you can see, I have a method called onDIComplete() which is called by BlenderBox after all dependency injection is finalized. Basically, my component has been created, injected and now it will be configured. I get some settings from my configuration bean, call my dao for a program record and finalize. Simple stuff, so let's test this puppy. First of all, I will create my setup method with my target cfc and dependencies. function setup(){
/* Create Mocks */
mockDAO = getMockBox().createMock(className="beta2007.beta94.model.betaweb.BetaDAO",clearMethods=true,callLogging=true);
mockConfig = getMockBox().createMock(className="coldbox.system.beans.configBean",clearMethods=true);
/* Mock Individual Settings */
mockConfig.$("getKey").$args("programID").$results("pid123");
mockConfig.$("getKey").$args("DefaultPublicRole").$results("BetaUser");

/* Create Target Service,decorate it with Mocking Capabilities, and init it
All in one single line via MockBox
*/
beta = getMockBox().createMock(className="beta2007.beta94.model.betaweb.BetaTransferService",callLogging=true).init();
/* Inject Mocks */
beta.$property("betaDao","instance",mockDao);
beta.$property("configBean","instance",mockConfig);
} What I do first is create my mock dao and mock config object. I then proceed to mock the 'getKey' method in my config object with several key target arguments and what they should return. Then I create my target object to test wich I also want decorated with mocking capabilities (just in case I need method spies) and init it. I then proceed to inject it with the mock objects into their appropriate variables in the correct scope /* Inject Mocks */
beta.$property("betaDao","instance",mockDao);
beta.$property("configBean","instance",mockConfig); So by leveraging MockBox's $property() method, I can inject properties into my target object. This is how I inject my dependencies. So let's proceed now to see my onDiComplete test. function testonDiComplete(){
/* Fake Program Record via ColdBox querySim() */
pRecord = querySim("program_id,name,release_phase_id,active,published
       #createUUID()#|Beta Program|#createUUID()#|1|1");
/* Mock Dao Call */
mockDAO.$("getProgramRecord",pRecord);   
/* Run onDI Complete */
beta.onDIComplete();
/* My Asserts */
assertEquals(precord, beta.getProgramRecord(),"program record");
assertEquals(beta.getProgramID(),'pid123');
assertEquals(beta.getDefaultPublicRole(),'BetaUser');
} So in my DI complete test, I first mock a query by using the ColdBox's querysim() method, I then mock the call to my dao's getProgramRecord, with this query I just mocked. I then call the onDiComplete() for execution and finalize with some assertions to make sure everything ran smoothly. So there you go, with a few lines of MockBox and testing, you can now be on your way to smoother and pain free testing. So go forth and Mock the Box!!

The ColdBox configuration file has a place for you as the developer to create as many custom setting variables as you like.  You can create simple or complex settings via JSON notation.  This approach is great, but sometimes, you want for these variables to be, well, more dynamic.  The following UDF helps you achieve this, by storing your name-value pairs of settings in a persisten storage such as a database.  Then just basically call this UDF from your application start handler and voila!! You are ready to roll with settings that can be managed from a control panel of your application or any other dynamic approach.  You can even get creative and create your own reloading techniques for only application settings. <cffunction name="loadOptions" access="private" returntype="void" hint="" output="false" >
   <cfset var qOptions = 0>
   <cfset var jsonRegex = "^(\{|\[)(.)*(\}|\])$">
   <cfset var oUtilities = getPlugin("Utilities")>
   <cfset var thisValue = "">
   <cfset var oJSON = getPlugin("json")>
   
   <!--- Get Options From the DB, my case is the SiteManager Dependency --->
   <cfset qOptions = getSiteManager().getOptions()>
   
   <!--- Loop --->
   <cfloop query="qOptions">
      <cfset thisValue = oUtilities.placeHolderReplacer(trim(qOptions.value),getSettingStructure())>
      <cfif reFindNocase(jsonRegex,thisValue)>
         <cfset setSetting(qOptions.name, oJSON.decode(replace(thisValue,"'","""","all")) )>
      <cfelse>
         <cfset setSetting(qOptions.name, thisValue)>
      </cfif>
   </cfloop>
</cffunction> There you go!!