RIA CFML Flex Flash

Using do as the event name in Coldbox, don't.

Tue, 20 Oct 2009 07:10:00 -0700

It took me a day to figure this out, live and learn right. I used 'do' as the event name in one of my Coldbox applications as opposed to 'event' given as the default. If you're considering what to name your events in Coldbox, don't. Just use the default 'event' name given. I was just trying to be unique but it backfired. The 'do' term is a reserved keyword in Flex, ActionScript actually. The lesson I got from this is to not ever use any keywords from any language for which you may mix. In this case I was using Flash remoting from my Flex application to to fire remote ColdFusion functions from the Coldbox framework remote proxy. Here is the code I was using in my Flex actionscript. Notice the 'event' object param passed to the proxy process function, you can't use 'do', well technically you can but don't because it won't work.


private function authenticateClient():void {
	var cProxy:RemoteObject = getColdBoxProxy();
	cProxy.addEventListener(FaultEvent.FAULT,faultHandler);
	cProxy.process.addEventListener(ResultEvent.RESULT,authenticateHandler);
	cProxy.process({event:"general.doRemoteLogin"});
}
/* UTILITY METHOD TO GET A CBPROXY OBJECT, You can separate all this to a delegate class */
public function getColdBoxProxy():RemoteObject{
    var cProxy:RemoteObject = new RemoteObject("ColdFusion");
    cProxy.source = _model.cbProxyPath;
    cProxy.showBusyCursor = true;
    return cProxy;
}

Consume object or object property

Sat, 20 Jun 2009 07:03:00 -0700

Here it is in a nutshell. I have a controller cfc in my framework that directs execution instructions to the business model cfc's. But I'm wandering if I should pass whole objects, like a user object, and get values as needed from it's methods within the business model? Or should I just pass the object's properties to the business model classes as needed? Another way to put it is this(model/securityService.cfc):


instance.securityGateway.login(User.getUsername(),User.getUserpassword());

or

instance.securityGateway.login(User);

The business model gateway in this example would be something like(model/data/gateway/securityGateway.cfc):





...


or



..

Maybe because I'm not a seasoned OO veteran but I'm looking at this and trying to figure out the best course and can't decide which one to take. From the service cfc do I pass in the user object or it's properties (username & password)? For now I'm passing the object's properties if the gateway method only requires data and doesn't need to access any of the objects other methods like setters. If the gateway method here needed to use the object's methods instead of just it's properties, then I'd pass the entire object. So what do you think is best practice?

CFC Method Testing in Coldbox

Wed, 20 May 2009 18:31:00 -0700

I got tired of trying to get cfUnit working and all I wanted to do was test component methods. I wanted to be able to simply point to it, test it, and enter arguments if required. And I wanted this set up somewhere easy I could use quickly, repeatedly, effortlessly, and painlessly (word?). In almost all my applications I have a 'webmaster' directory where I run test. Lately I've found myself getting fancy with setting up a web development control panel of sorts. Whereas web sites generally have administration control for admin users, I've been building in webmaster control for developers. Mostly things like server and framework info, links to documentation, framework and site functionality examples, and etc. Now I'm adding a little CFC Test form where I enter my cfc path, the method name, and arguments. It will pass the event argument so you can also test cfc handlers. Warning, I just created this a few hours ago. It's tested to work but I haven't cleaned it up or put in validation and error handling yet. views/webmaster/index.cfm (webmaster control panel)


	
	
	Enter Component Path:

	

	Enter Method to Test:

	

	Arguments:(comma seperated list)

events/webmaster/panelcontrol.cfc (Coldbox handler)


	
	
	
	
	
		
			
		
	
	
	
		//Display
		event.setValue("cfctestresults",ret);
		event.setValue("author","Clint Willard");
		event.setView("webmaster/dspCfcTestResult");

Basically it loops through the method arguments list you entered in the form setting them as part of the arguments struct. That arguments struct is then passed to the invoked component and method, along with the event object. Then the view is set to output with the test results, whatever the method is set to return. views/webmaster/dspcfcTestResult.cfm


	cfcresult = event.getValue("cfctestresults","NA");


	#dump(cfcresult)#

KISS output. Let me know if this might be a good idea to expand on or should I just LOL learn cfUnit? And the webmaster information and control panel stuff?

Coldbox model mappings script

Sun, 17 May 2009 21:10:00 -0700

Tired of keeping your modelMappings.cfm file straight everytime you add or delete a model? What you need is a script that'll do it all automatically. This code isn't mine and I can't remember where I found it but it's very useful. Mind the OS slashes '/' and '\', change as needed for your system, Windows or *nix, which can probably be parameterized too.

  
/**  
* Deletes the n leftmost elements from the specified list.  
* Modified by RCamden  
*  
* @param list      The list to modify.  
* @param numElements      The number of elements to delete from the left hand side.  
* @param delimiter      The delimiter to use. Defaults to a comma.  
* @return Returns a string.  
* @author Shaun Ambrose (shaun.ambrose@arcorsys.com)  
* @version 1, April 24, 2002  
**/  
function ListDeleteLeft(list, numElements) {   
    var i=0;   
    var delimiter=",";   
       
    if (Arraylen(arguments) gt 2) {   
        delimiter=arguments[3];   
    }   
           
    if (numElements gt ListLen(list, delimiter)) return "";   
       
    for (i=1; i lte numElements; i=i+1) {   
        list=listDeleteAt(list, 1, delimiter);   
    }   
    return list;   
}

Coldbox Bean Factory

Thu, 14 May 2009 14:50:00 -0700

Coldbox has a really cool bean factory that can speed up your development time. Through it's methods you can manage your bean objects with one-liners. Like, instead of having your handler get a bean form the gateway then filling or updating that bean with it's getters, you can simply tell the bean factory to do it for you.

UserBean = getPlugin('beanFactory').getModel('data.bean.User');
getPlugin('beanFactory').populateBean(UserBean);

The example you see above gets a bean and populates or updates its properties via its setters automatically. Your next question is "With what?" Let's imagine a form that a user fills out to update his address. Nevermind the code I'm typing from my head, it's short to be to the point.

Notice the name property for the text input where the address goes, 'address', case isn't important. It gets handled by the general handler in the events directory as an editAddress event, which runs the editAddress method of the general handler object. And in the general handler is the editAddress event.





getPlugin('beanFactory').populateBean(variables.UserBean);
getPlugin('beanFactory').getModel('data.gateway.usersGateway').saveBean(variables.UserBean);

With just this much code, after the form was submitted, my handler, with the bean factory, has updated the bean property 'address' and used the gateway to update it in the database. The populateBean method takes the request context, which contains the submitted form items such as 'address=1732 Main St.' and finds the setter method matching the form names, or 'address' in this case. Then it runs the setAddress() method of the bean, updating it. You don't have to call out the bean's actual setter method in your code which is fantastic when your form has many more fields. You can also set a value in the request context that matches a bean's property name and then just use populateBean() to update it. The following code will include an update to the name properties of the user bean. If the user bean object has a setFirstName() and setLastName() method, then it's first and last name properties will also be updated.





rc.firstName = "Clint";
rc.lastName = "Eastwood";
getPlugin('beanFactory').populateBean(variables.UserBean);
getPlugin('beanFactory').getModel('data.gateway.usersGateway').saveBean(variables.UserBean);

After the code above runs, UserBean.getFirstName() will return 'Clint' now. As long as the property is spelled the same, 'firstname'. You want to keep your object property names the same as in your database. Maybe some time I'll go over the bean factory's model mapping and autowire methods but for now I'm not using them and haven't yet found a reason to.

ColdBox Model Dependencies

Wed, 13 May 2009 17:31:00 -0700

I found another way in ColdBox to inject dependencies within my model and data layer. I'm not sure if it's newer or older than my current IOC only injection



...




	







	




...

but it sure seems easier, cleaner, and coder intuitive. I'm still using ColdSpring IOC for my data layer but now I'm using ColdBox's own model injection. It (beanFactory) uses a modelMappings.cfm file in the config directory to list the metadata that's like model mappings.


cfscript>
/* Add all the model mappings you want */
/* addModelMapping(alias="",path="") */
addModelMapping(path='UsersService');
addModelMapping(path='data.bean.Users');

Its intuitive enough to map the model name from the path or you can use an alias instead. Whether or not a huge application with a few thousand classes would bloat this file and slow things down would be an interesting question. But for now what makes this way better to me would be the more intuitive feeling of the metadata style dependency listings using the cfproperty tag in all my models





...



//Logic
userName = instance.usersService.getUserName();
//Display
Event.setValue('userName',userName);
Event.setView("test");


...

and frankly the modelMappings meta listing style actually helps with mental organization. I'm not sure if this way is supposed to be better, worse, or just different but I love it.

Coldbox Development Environment

Tue, 12 May 2009 08:15:00 -0700

One of the newest enhancements to Coldbox (2.6) is an environments.xml.cfm file in the config directory you can use to override application settings depending on what box your on. Even if you work on a DEV server, test on a QA server, and publish to the PRODUCTION server, you can set settings like caching and auto reloading for each box and forget it. For example you can set in the coldbox.xml.cfm for production but override that in environments.xml.cfm with <Setting name="DebugMode" value="true" />. So if your dev environment url parameter in the environment.xml.cfm is 'localhost', then when the cgi.http_host equals 'localhost' instead of 'mysite.com' the debugmode value will be 'true'. And without changing a thing, it will be 'false' in production. There is no need to set a production environment in environments.xml.cfm as CB will use coldbox.xml.cfm settings only if cgi.http_host isn't found.

Coldbox Framework and Ajax: cfajaxproxy

Thu, 16 Oct 2008 08:19:00 -0700

After working in Coldbox for a while I know your first instinct is to make a cfajaxproxy call to a cfc event just like all the other Coldbox events. However, using cfajaxproxy is just a little different. Here is an example to show you one simple way of doing it, not the only way but one of them. First let me note that I am using Coldspring version of IOC. It should work the same though with any form of IOC. Mostly we need the IOC to provide the bean to the services your Ajax call requires from within the Coldbox proxy. After having provided a service in Coldspring like so:

we can use this "usersService" bean in the coldboxproxy.cfc like this:

The code above is what the Ajax, cfcajaxproxy, will call as a method for Coldbox to perform. It fetches a private message object bean, sets or updates some properties, then uses the gateway to save the object bean. I don't have a return or output but you can do that also here if desired. And here is the actual view and Ajax calling code:




#privateMessagesQuery.subject#

<$cript>
function showMessageDetails(messageid,read,subject,from,message){
	var e = new cbProxy();
	if(read == 0){
		e.setCallbackHandler(setPrivateMessageRead);
	    e.setErrorHandler(ajaxErrorHandler);
	    e.ajxSetPMRead(messageid);
	}
	document.getElementById('pmReply').style.display = "none";
	document.getElementById('pmDetails').style.display = "inline";
	document.getElementById('pmDetails_Subject').innerHTML=subject;
	document.getElementById('pmDetails_From').innerHTML=from;
	document.getElementById('pmDetails_Message').innerHTML=message;
}
var setPrivateMessageRead = function(res){
	alert('set to read');
}
var ajaxErrorHandler = function(statusCode, statusMsg){
	alert('Status: ' + statusCode + ', ' + statusMsg);
}

The cfc attribute is dot notation to the location of your coldboxproxy.cfc, mine here is at the root. Basically I'm showing the private message details in a div but needing to set the read flag in the database to 1 to indicate it has been read. And using Ajax I can set this in the database for each message read without a page refresh. The alerts in the javascript are for demonstration and testing purposes. The code I provided is a cut down version of actual code and does not include the view event, form code, queries, or other behind the scenes code. I hope this helps to give you a step ahead on how to use Ajax with the Coldbox framework.

Create Coldbox plugin example

Fri, 06 Jun 2008 06:13:00 -0700

Coldbox plugins are a really useful aspect of the framework when you want to create reusable interfunctions. Interfunction is a term for a function within an application that can be used in any application within any one specific framework. Coldbox plugin interfunctions are, to me, like UDFs, almost. Except that they are OO capable components. But enough with talk, read more about plugins here. And here's an example of a custom plugin I created called "MyUtilities" that has a function utilizing CF8's new image resizing abilities. It's not expanded yet as this is just what I needed for the moment on a project. This goes into a cfc (MyUtilities.cfc) file in your plugins directory, I called this plugin "MyUtilities" for now:


			
	
		
		
		
		
		
			if(IsImageFile("#arguments.fileLocation#")){
				myImage		= ImageNew(arguments.fileLocation);
				ImageSetAntialiasing(myImage,"on");
				ImageScaleToFit(myImage,arguments.xWidth,arguments.yHeight,"highestQuality");
				ImageWrite(myImage,arguments.destination,1);
				return ImageInfo(myImage);
			}else{
				return false;
			}

And this is how you'd use it in your code: imageThumb = getPlugin("MyUtilities",true).resizeImage(fileLocation,thumbLocation,width,height); You can see from the resizeImage function that I hard coded resize quality and antialiasing, as that is true anywhere in my project for all image sizing. But you can take this and customize it further for your needs. I just mostly wanted to share with you an example of using a custom Coldbox plugin.

Coldbox beanfactory populatebean method

Wed, 04 Jun 2008 19:20:00 -0700

I have to say I love this automatic bean population thing going around. Model-Glue does it also but since I mostly use Coldbox, that's what I'm showing here. WTF, you may ask? Well, you know how when you submit a form to edit a user account for example, and then you have to pass all those form elements to your user bean object's getters and setters one by one. userObj.setUsername(form.username), userObj.setUserpassword(form.password) and so on.. well you can forget about ever doing this again. HOW!?!? By using the Coldbox beanfactory populatebean method. You can play with form elements first if you need to, then simply call the populate method passing in the current userbean, and then Coldbox will match form elements to the bean's getter and do the heaving lifting for you returning an updated bean ready for saving. 2 simple lines, get bean and populate bean. Then do whatever else you prefer from there to save it wherever etc..


		
		
		
			userBean = getPlugin("sessionstorage").getVar("User");
			getPlugin("beanFactory").populateBean(userBean);
			getUsersService().saveUser(userBean);
			getPlugin("sessionstorage").setVar("User",userBean);

The most important thing to remember is that your actual bean cfc object must use an init method with setters. And the form element names should be the same as the bean names. A bean's init:

So that: Matches:

Hope that helps. :)

Dynamic column layouts in Coldbox

Sun, 01 Jun 2008 10:37:00 -0700

Possibly like me, you have a site that can be thought of as sections. An example would be an ecommerce site with product categories such as electronics, garden, books, movies, and others. The idea behind dynamic columns in Coldbox is that for each section I just mentioned, you may want to display content in the left column of your site specific for that section only and an element or two common to all of them. There may very well be several ways to accomplish this small task and I'm going to show you one of mine. So lets just jump right in. If you're like me, your just skimming though this any ways and so I'll just make a list type explaination.

This example uses one layout file for multiple sections of the site where each section will have a different left column layout.

Each section will have it's own left column display file.

Each column file will render boxes within it ordered as needed.

So your views directory would look something like:
-views
   -boxes
     menu.cfm
     tvSuppliers.cfm
     gardenTips.cfm
     weather.cfm
     information.cfm
   -elements
     header.cfm
     footer.cfm
     leftColumn_Electronics.cfm
     leftColumn_Garden.cfm
   -electronics
     home.cfm
   -gardens
     home.cfm
And here's how the layout template uses these elements:




	
		#renderView('elements/header')#
	
	
		
			
				
					#renderView('elements/leftColumn_Electronics')#
				
				
					#renderView('elements/leftColumn_Garden')#
				
				
					#renderView('elements/leftColumn')#
				
			
		
		
			#renderView()#
		
	


	#renderView('elements/footer')#

And in the elements, you place the boxes you want, order and whatever layout.
leftColumn_garden.cfm for example:


	#renderView('/boxes/menu')#
	#renderView('/boxes/gardenTips')#
	#renderView('/boxes/information')#

And of course the handler. I usually place the layout variables in here as such:

That's it and about as simple a plan as I could come with in my limited Coldbox knowledge. I'm sure it can be automated somewhat a little more or better simplified. Frankly I couldn't find any info online myself to show such an example but your more than welcomed to one up on me. Hope this helps.

ColdSpring ColdboxFactory: DSN and Mail settings

Mon, 26 May 2008 06:06:00 -0700

My second day into figuring out Coldbox, here's a little something cool. Putting it simply, using ColdSpring, in the CS.xml you can define a 'coldboxFactory' bean to use in creating other beans that define this factory's methods as beans also, then pass that bean into a class bean's property as a bean reference. Actually, that doesn't sound simple as it is, so here's an example. Remember that I'm a newbie, so be nice. coldbox.xml.cfm



	mail.urserver.com
	25
	username
	password

I've set mail settings and data source settings here in the main Coldbox config. I'll be using Coldspring for IoC and so I'll need to be able to pass this around in my beans. Coldspring.xml



	
	
	
	
	   
	       DSNAlias

This coldboxFactory has several methods that interface with the coldbox config file, among other things I'm sure. Check out the API for more info. But basically I create the coldboxFactory bean, then create other beans of the factory's methods. Then notice how I pass those beans into the handler beans by reference. These 'properties', as it turns out, are setters in the cfc, such as setDsnBean and setConfigBean. Then I just put them in variables for my other methods. cfctest.cfc

Don't dis my cfc, I'm just playing around and testing stuff. Notice the setters that I mentioned before. If you do a dump/abort on these at run time you'll see what use they are. general.cfc

And finally here's the handler that uses the IoC plugin I set in variables in the handler's init function that gets the bean set in Coldspring and runs the method that utilizes all the stuff we just went through. Check out Coldbox's Coldspring documentation for more information. There are other factories to use I'm guessing and other factory methods within those. You can use all the methods in the coldbox.system.controller as beans also. But like I said, I'm just discovering this stuff right now. Frankly I need to think over wether or not passing bean reference properties to all my CS beans is the most effective way of using global configs any ways. Seems rather repetative as apposed to putting such things in a request scope through onRequestStart or something.