Brian Kotek: Inversion of Control - ColdFusion

BlazeDS and LCDS RPC Call Ordering

Wed, 14 Sep 2011 09:11:00 -0700

I'm working on a project that is performing "real-time saving" of data in a Flex UI. In other words, if they do something in the UI, that change is saved to the database automatically, rather than waiting until the user presses a save button. One concern we had was what happens if multiple requests are sent to the server, and for whatever reason some take longer to complete than others? i.e. you send RequestA then RequestB, and RequestA takes 10 seconds but RequestB takes 1 second. Which would mean the database would end up being wrong, with the data from RequestA being the last version saved. How can we make sure that the final state persisted in the database is actually the current state, and not the last request that happened to complete? A number of options were thrown on the table, including implementing a client and/or server-side queue, or building logic to verify that the current state in the client matches the persisted state. While mulling this over, one of my colleagues noticed an interesting line in the LCDS documentation:

Channels also impose an order to the flow of messages sent to the server and the order of corresponding responses. Order is important to ensure that interactions between the client and server occur in a consistent, predictable fashion.

It's rather vague, but we read that to say "even though you think your calls to the channel are asynchronous, they actually aren't." Which, even though it is not what I thought was going on at all, would mean that the problem I mentioned earlier actually isn't a problem at all. Tom Jordahl was kind enough to respond to an email and discuss this. I then ran a number of tests locally to confirm the behavior. It turns out that calls to Messaging Channels are totally asynchronous, but calls by the same client to the same RPC Channel are synchronous. Which means if you send RequestA then RequestB, they will be processed in that order and the results will come back in that order. Regardless of how long either of them take to complete. You can still run asynchronous RPC calls from the same client, but they would have to call different Channels. So the option is there if you need it. I wanted to blog this because I've been using remoting for a long time and never knew this. In fact, I always assumed the opposite was true. So, this is a big deal for two reasons: if you need to ensure the order of your RPC calls, you can. And conversely, if you think your RPC calls to the same Channel are running asynchronously, they actually are not! And this applies whether you're using a Java back end with BlazeDS/LCDS, or using ColdFusion with its BlazeDS integration.

Using ColdFusion ORM and HQL, Part 5: Optimizing with HQL

Tue, 21 Sep 2010 07:49:00 -0700

In this entry, I want to take a look at using HQL to reduce unwanted database queries. As with any optimization, the first thing to do is identify the problem. So lets take a look at how Hibernate does things by default. When you create a relationship between entities, the default fetching behavior for the relationship is called "lazy". Which means that Hibernate won't try to load up the associated objects until something actually asks for them. And in some cases, this is perfectly fine. But in other cases, it can cause a lot of overhead. Consider the relationship between a BlogEntry and a BlogComment. If you recall, this is a bidirectional relationship, where a BlogEntry has many BlogComments, and a BlogComment has one BlogEntry. That means if I load up a BlogComment, by default the associated BlogEntry is not loaded yet. Only when some code tries to access the comment's BlogEntry does Hibernate actually create that object. And that may be fine if I'm only dealing with one comment. But consider a situation where I want to show all of the comments that have been posted by a specific user, along with the BlogEntry where the comment was posted. I might have a simple DAO method that looks like:

js|
function commentsByUser( id )
{
	return OrmExecuteQuery( "SELECT c
				 FROM 
				 	BlogComment c
				 WHERE 
				 	c.createdBy.id=:id",
				 {id=arguments.id} 
				);
}

Which will generate SQL like this:

sql|
09/20 22:29:09 [jrpp-1] HIBERNATE DEBUG - 
    select
        blogcommen0_.id as id2_,
        blogcommen0_.content as content2_,
        blogcommen0_.dateCreated as dateCrea3_2_,
        blogcommen0_.entryId as entryId2_,
        blogcommen0_.createdBy as createdBy2_ 
    from
        BlogComment blogcommen0_ 
    where
        blogcommen0_.createdBy=?

The query gets all of the comments posted by the user. I can loop over them, showing the comment along with the name and date of the blog entry. However, the overhead caused by the lazy loading will increase as the number of comments I'm displaying goes up. For example, if a user has posted three comments, Hibernate will run the following queries when I try to display this information:

sql|        
09/20 22:29:09 [jrpp-1] HIBERNATE DEBUG - 
    select
        blogentry0_.id as id0_0_,
        blogentry0_.content as content0_0_,
        blogentry0_.dateCreated as dateCrea3_0_0_,
        blogentry0_.title as title0_0_,
        blogentry0_.createdBy as createdBy0_0_ 
    from
        BlogEntry blogentry0_ 
    where
        blogentry0_.id=?

09/20 22:29:09 [jrpp-1] HIBERNATE DEBUG - 
    select
        blogentry0_.id as id0_0_,
        blogentry0_.content as content0_0_,
        blogentry0_.dateCreated as dateCrea3_0_0_,
        blogentry0_.title as title0_0_,
        blogentry0_.createdBy as createdBy0_0_ 
    from
        BlogEntry blogentry0_ 
    where
        blogentry0_.id=?

09/20 22:29:09 [jrpp-1] HIBERNATE DEBUG - 
    select
        blogentry0_.id as id0_0_,
        blogentry0_.content as content0_0_,
        blogentry0_.dateCreated as dateCrea3_0_0_,
        blogentry0_.title as title0_0_,
        blogentry0_.createdBy as createdBy0_0_ 
    from
        BlogEntry blogentry0_ 
    where
        blogentry0_.id=?

As I iterate over each comment to show the blog entry information, Hibernate must execute separate queries for each entry. This is how the lazy loading works. The associated objects are built on an as-needed basis. As you can see, if I were showing 30 comments, that would be one query to get the comments, and then 30 queries to create each related BlogEntry. That's a lot of separate queries, especially if I know in advance that I will need them all. One option is to modify the association to specify fetch="join", like this:

js|[1]|
property name="blogEntry" fieldtype="many-to-one" fetch="join"
		fkcolumn="entryId" cfc="BlogEntry" notnull="true";

This tells Hibernate "every time you load a BlogComment, I want you to load the associated BlogEntry at the same time". This will cause the objects to be loaded in one SQL statement, eliminating the extra queries. Unfortunately, it's a very brute-force approach. I'd better be really sure that I always want the associated blog entry with every comment. Otherwise, I'm just switching one problem for another: I'll be loading a bunch of extra data if all I actually want are the comments! To be honest, I'm not happy with this all or nothing decision. The good news is, I can leave the association lazy by default, but use HQL to perform JOIN fetching for situations where I want to load all of the data at once. The method in my DAO might look like this:

js|[6]|
function commentsByUser( id )
{
	return OrmExecuteQuery( "SELECT c
				 FROM 
				 	BlogComment c 
				 	JOIN FETCH c.blogEntry b
				 	JOIN c.createdBy u
				 WHERE 
				 	u.id=:id",
				 {id=arguments.id} 
				);
}

As you can see, I'm telling hibernate to fetch the blog entry data along with the comments. The resulting SQL would look like:

sql|
09/20 22:30:11 [jrpp-1] HIBERNATE DEBUG - 
    select
        blogcommen0_.id as id2_0_,
        blogentry1_.id as id0_1_,
        blogcommen0_.content as content2_0_,
        blogcommen0_.dateCreated as dateCrea3_2_0_,
        blogcommen0_.entryId as entryId2_0_,
        blogcommen0_.createdBy as createdBy2_0_,
        blogentry1_.content as content0_1_,
        blogentry1_.dateCreated as dateCrea3_0_1_,
        blogentry1_.title as title0_1_,
        blogentry1_.createdBy as createdBy0_1_ 
    from
        BlogComment blogcommen0_ 
    inner join
        BlogEntry blogentry1_ 
            on blogcommen0_.entryId=blogentry1_.id 
    inner join
        `User` user2_ 
            on blogcommen0_.createdBy=user2_.id 
    where
        user2_.id=?

Which means the BlogEntry will be loaded up along with the BlogComments, all from a single query. In this context, that's going to be a great deal more efficient than executing separate queries for every association. I hope you can see that a big advantage of using HQL is the fine-grained control it offers when it comes to loading objects. I should have one or two more looks at some other scenarios where HQL can help you optimize your application, so stay tuned!

Using ColdFusion ORM and HQL, Part 4: Basic Filtering and Sorting

Wed, 15 Sep 2010 08:52:00 -0700

Now that we've got our domain model set up, associations created, and relationships managed, I want to delve into the topic of HQL. In case you aren't aware, HQL is an "object-centric" query syntax that gives you very fine-grained control over what Hibernate is doing when you ask it to retrieve objects from the database. I'll say up front that I am a proponent of using data access objects (DAOs) to encapsulate interaction with the database. In essence, that means the only place that really should know about the database, Hibernate, or HQL is within the DAOs. So the examples I'm going to show are created as methods within a DAO. We'll start with some simple sorting and filtering. This is a common requirement, and HQL makes it very easy to do:

js|	
function allEntries()
{
	return OrmExecuteQuery( "FROM 
					BlogEntry b 
				 ORDER BY 
					b.dateCreated DESC" );
}

That simply gets all of the blog entries, sorted by the date they were created.

js|
function mostRecentEntry()
{
	var results = OrmExecuteQuery( "FROM 
						BlogEntry b 
					ORDER BY 
						b.dateCreated DESC", 
					false, {maxResults=1} );
	return results[1];
}

As the name implies, the above HQL would get the most recent blog entry.

js|
function entriesByUser( id )
{
	return OrmExecuteQuery( "SELECT b 
				FROM 
					BlogEntry b 
					JOIN b.createdBy u
				WHERE 
					u.id=:id",
				{id=arguments.id} );
}

Here, we start leveraging the object relationships. In this case, I'm getting all of the blog entries that were created by the specified user.

js|
function entriesWithCommentsFromUserName( userName )
{
	return OrmExecuteQuery( "SELECT DISTINCT b 
				FROM 
					BlogEntry b 
					JOIN b.comments c 
					JOIN c.createdBy u 
				WHERE 
					u.name LIKE :userName",
				{userName='%#arguments.userName#%'} );
}

And finally, the above HQL loads all BlogEntries that have a comment which was posted by a user matching a user name search string. This is a fairly contrived example, since I'm not sure a blog application would actually need to do this. But on the ORM mailing list, I've seen several people with the need to filter the objects based on a property from a collection of related objects. To make it more clear, this is the actual SQL that Hibernate would generate under the hood for this HQL:

sql|
09/15 00:58:17 [jrpp-2] HIBERNATE DEBUG - 
select
        distinct blogentry0_.id as id0_,
                blogentry0_.content as content0_,
                blogentry0_.dateCreated as dateCrea3_0_,
                blogentry0_.title as title0_,
                blogentry0_.createdBy as createdBy0_ 
        from
                BlogEntry blogentry0_
                inner join
                BlogComment comments1_ 
                	on blogentry0_.id=comments1_.entryId 
                inner join
                	`User` user2_
                	on comments1_.createdBy=user2_.id
        where
        		user2_.name like ?
            		
09/15 00:58:17 [jrpp-2] HIBERNATE DEBUG - binding '%Tom%' to parameter: 1

The SQL itself may seem obvious to anyone familiar with SQL. But since Hibernate is dealing with objects and properties, it can sometimes take a bit of trial and error to work out how traverse properties that are collections of objects. I will stop here for today. In the next entry, we'll focus on using HQL to optimize the loading of larger object graphs.

Using ColdFusion ORM and HQL, Part 3: Bidirectional Relationships

Tue, 14 Sep 2010 08:16:00 -0700

In this entry I want to take a closer look at the relationship I have set up between BlogEntry and BlogComment. Since I want to be able to ask an entry for its comments, and I also want to be able to ask a comment for its entry, this is a bidirectional relationship. As a result, this takes a bit of additional thought to get working optimally. Recall that BlogEntry looks like this right now:

js|
component displayname="BlogEntry" extends="Entity" output="false" 
		  persistent="true" accessors="true"
{
	property name="title" type="string" ormtype="string";
	property name="content" type="string" ormtype="text";
	property name="categories" singularname="category" fieldtype="many-to-many" 
  		     cfc="BlogCategory" linktable="entry_category" 
  		     fkcolumn="entryId" inversejoincolumn="categoryId";
	property name="comments" singularname="comment" fieldtype="one-to-many"
  		     cfc="BlogComment" fkcolumn="entryId" 
  		     orderby="dateCreated ASC" inverse="true";
	
	BlogEntry function init()
	{
		variables.categories = [];
		variables.comments = [];
		return this;
	}	
}

And that BlogComment looks like:

js|
component displayname="BlogComment" extends="Entity" output="false"
		  persistent="true" accessors="true"
{
	property name="content" type="string" ormtype="text";
	property name="blogEntry" fieldtype="many-to-one" 
 	  	     fkcolumn="entryId" cfc="BlogEntry";  
}

The first thing to make note of is that the comments collection in BlogEntry is marked as inverse. As I (and others) have mentioned previously, it is important to designate one side of a bidirectional relationship as the owning side. By setting the comments collection as inverse, I am telling Hibernate that the other side of this relationship is the owning side. In other words, the blogEntry property in BlogComment is the owner of this relationship. This has a very important effect on the relationship: Hibernate will ignore all persistence operations regarding this relationship on the side that is marked as inverse. Which means that in order to get Hibernate to properly save this relationship, I must set the blogEntry property in BlogComment. Put another way, I'm telling Hibernate: "when it comes to his relationship, I want you to use the blogEntry property of BlogComment to dictate what you persist to the database". I need to emphasize one additional point, which is that even though Hibernate only cares about what is set into the blogEntry property when it comes to persisting my data, my domain model most certainly cares about both sides of the relationship. If I set the blogEntry property on one of my BlogComments, then that BlogComment better be present in the comments collection of my BlogEntry. So it looks like we have two different issues. First, how do I make sure the owning side of the relationship (the blogEntry property) is always set correctly. And second, how do I make sure that the collection of BlogComments in a BlogEntry is also kept up to date? At first glace, the solution might just be to dictate that anyone who wants to set up this bidirectional relationship needs to know that they should always do both comment.setBlogEntry( blogEntry ) and blogEntry.addComment( comment ). And that will certainly work. But it's a poor solution, and the reason why is probably obvious: if someone forgets to set up both sides, my domain model spirals into an invalid state. The good news is that there is a simple best-practice way to enforce this relationship. It is called an association management method. Which just means I should create methods on my BlogEntry and my BlogComment to ensure that both sides are always set together. I'll start with the owning side, which in this case is BlogComment.

js|
component displayname="BlogComment" extends="Entity" output="false"
		  persistent="true" accessors="true"
{
	property name="content" type="string" ormtype="text";
	property name="blogEntry" fieldtype="many-to-one" 
 	  	     fkcolumn="entryId" cfc="BlogEntry" notnull="true";  

	function setBlogEntry( blogEntry )
	{
		if( !IsNull( arguments.blogEntry ) )
		{
			variables.blogEntry = arguments.blogEntry;		

			if( !arguments.blogEntry.hasComment( this ) )
			{
				ArrayAppend( arguments.blogEntry.getComments(), this );
			}
		}	
	}
}

The code is very straightforward, but just to make sure, I'll go through it. When a blogEntry is set on a BlogComment, the first thing I do is check to make sure the incoming blogEntry is not null. In my model, I can't have a comment without an entry. Next, I set the value of blogEntry to the incoming value. And finally, if the incoming blogEntry doesn't have this comment in its collection of comments, I add it to the comments collection. Since BlogComment already has all of the logic I need to set up the relationship, all I need to do in BlogEntry is delegate to the setBlogEntry method in BlogComment:

js|
component displayname="BlogEntry" extends="Entity" output="false" 
		  persistent="true" accessors="true"
{
	property name="title" type="string" ormtype="string";
	property name="content" type="string" ormtype="text";
	property name="categories" singularname="category" fieldtype="many-to-many" 
  		     cfc="BlogCategory" linktable="entry_category" 
  		     fkcolumn="entryId" inversejoincolumn="categoryId";
	property name="comments" singularname="comment" fieldtype="one-to-many"
  		     cfc="BlogComment" fkcolumn="entryId" 
  		     orderby="dateCreated ASC" inverse="true";
	
	BlogEntry function init()
	{
		variables.categories = [];
		variables.comments = [];
		return this;
	}	

	function addComment( comment )
	{
		comment.setBlogEntry( this );
	}
}

With these association management methods set up, I now know that any time someone sets a blogEntry on a comment, or adds a comment to a blogEntry, both sides of the relationship will always be set. I would strongly recommend that you adopt a strategy like this to enforce the rules for your bidirectional relationships. In the next few entries, I'll move on to the topic of HQL. I want to show some of the ways you can leverage HQL to optimize the way Hibernate interacts with the database.

Using ColdFusion ORM and HQL, Part 2: ORM Event Handler

Fri, 10 Sep 2010 08:35:00 -0700

In the previous entry, I described the basic blog application I want to create. We looked at the model, the relationships needed, and whipped up the CFCs to implement that model. One of the things I mentioned is that I want each entity to be able to keep track of when it was created and who created it. This could be done manually, but I like to avoid manual whenever I can. The good news is that we can easily do this automatically. The solution is to use Hibernate's event model. In Hibernate terms, the classes that are notified about persistence activities are called interceptors. Happily, the ColdFusion development team have given us access to this capability by letting us specify event handler CFCs in our ORM configuration. I should note that I am running CF 9.0.1 with the cumulative hotfix installed. I'll set up my Application.cfc like this:

js|
component name="Application.cfc" output="false"
{
    this.name = Hash( GetCurrentTemplatePath() );
    
    this.sessionManagement = true;
    this.sessionTimeout = CreateTimeSpan( 0, 0, 0, 10 );
    this.setClientCookies = true;
    this.setDomainCookies = true;
    
    this.appRoot = ExpandPath( '.' );
    this.mappings = {};
    this.mappings["/ormblog"] = this.appRoot;
    
    this.datasource = "ormblog";
    this.ormEnabled = true;
    this.ormSettings.dialect = "MySQLwithInnoDB";
    this.ormSettings.logSQL = true;
    this.ormSettings.saveMapping = false;
    this.ormSettings.eventHandler = 'ormblog.model.orminterceptor.AuditInterceptor';
    this.ormSettings.flushAtRequestEnd = false;
    this.ormSettings.autoManageSession = false;
    this.ormsettings.dbcreate = "dropcreate";
}

You can see that I'm specifying an AuditInterceptor CFC as an ORM event handler. Any event handler CFC we define must implement the CFIDE.ORM.IEventHandler interface, so my AuditInterceptor looks like this:

js|
import ormblog.model.domain.*;

component output="false" implements="CFIDE.ORM.IEventHandler"
{
    public void function preInsert( any entity )
    {
   	 entity.setDateCreated( Now() );
   	 if( IsNull( entity.getCreatedBy() ) 
             && StructKeyExists( session, 'currentUser' ) )
   	 {
   		 entity.setCreatedBy( EntityLoadByPK( 'User', session.currentUser ) );
   	 }
    }
    
    public void function preLoad( any entity )
    {
    }
    
    public void function postLoad( any entity )
    {
    }
    
    public void function postInsert( any entity )
    {
    }
    
    public void function preUpdate( any entity, Struct oldData )
    {
    }
    
    public void function postUpdate( any entity )
    {
    }
    
    public void function preDelete( any entity )
    {
    }
    
    public void function postDelete( any entity )
    {
    }

}

In my preInsert() method, I'm setting the dateCreated, and setting the createdBy to the currently logged in User. In a real application, I would probably avoid having my interceptor reach into the session scope by using ColdSpring to inject a Session Proxy object that encapsulates interaction with the session scope. But in the interest of keeping this example simple and focused, we'll just grab the current user's ID from the session scope. The end result of this is that any time I persist a new entity, the dateCreated and createdBy properties will be set automatically. And this could easily be expanded, for example if I ever want to track dateUpdated or updatedBy, etc. If I only wanted to perform this audit tracking on certain CFCs, rather than all subclasses of my Entity class, I could create another subclass of Entity called AuditableEntity and have my CFCs extend that, or I could create an Auditable interface and have my CFCs implement that interface. The AuditInterceptor could then be changed to only set the audit properties if the CFC being saved is of type AuditableEntity/Auditable. But I digress. ;-) We've now completed the automatic population of dateCreated and updatedBy. In the next entry I'll dig deeper into the bi-directional relationship between BlogEntry and BlogComment.

Using ColdFusion ORM and HQL, Part 1

Thu, 09 Sep 2010 08:48:00 -0700

Now that the Hibernate integration in ColdFusion 9 has been in use for a while, we're seeing an increasing number of questions on the CF-ORM mailing list. This isn't surprising, Hibernate is a vast topic in and of itself, and the CF documentation can really only scratch the surface. There are entire books just dedicated to using Hibernate (my personal favorite being Java Persistence with Hibernate). It's one thing to look at the documentation and understand the simple use cases, but quite another to actually get into real world application development with Hibernate. With this in mind, I'm going to be posting a few blog entries that explore using CF and Hibernate in some more complex scenarios. The end result will be a rudimentary blog application, and I'll post that code in the last blog entry on this topic. But before we get to that, I want to back up and look at how one might approach the design of this application. Here is a simple UML diagram of the domain model I want to create: Contrary to good OO design, I'm not focusing on the behavior of these objects at all due to the fact that this is specifically an ORM example. I am also making the following assumptions, which affected the way the associations were defined, and will drive some later decisions when it comes to loading the objects:

A BlogEntry will typically be associated with a few BlogCategories (between one and four, but maybe a few more)
A large number of BlogEntries (hundreds or thousands) can be associated with a BlogCategory
A low to moderate number of BlogComments can be associated with a BlogEntry (probably up to a few dozen unless the entry triggers an unusual number of comments)
Each entity should keep track of when it was created and who created it

With this in mind, the relationships are defined as follows:

One User can be associated with many Entities via the createdBy property
One BlogCategory can be associated with many BlogEntries
Many BlogComments can be associated with a BlogEntry
One BlogEntry can be associated with a BlogComment

Translated into code, the entities look like this:

js|
component displayname="Entity" output="false" mappedsuperclass="true" accessors="true"
{
	property name="id" fieldtype="id" type="numeric" ormtype="int" generator="native";
	property name="dateCreated" type="date" ormtype="timestamp";
	property name="createdBy" fieldtype="many-to-one" cfc="User" fkcolumn="createdBy";
}

js|
component displayname="User" extends="Entity" persistent="true"
		  output="false" accessors="true"
{
	property name="name" type="string" ormtype="string";
}

js|
component displayname="BlogEntry" extends="Entity" output="false" 
		  persistent="true" accessors="true"
{
	property name="title" type="string" ormtype="string";
	property name="content" type="string" ormtype="text";
	property name="categories" singularname="category" fieldtype="many-to-many" 
  		     cfc="BlogCategory" linktable="entry_category" 
  		     fkcolumn="entryId" inversejoincolumn="categoryId";
	property name="comments" singularname="comment" fieldtype="one-to-many"
  		     cfc="BlogComment" fkcolumn="entryId" 
  		     orderby="dateCreated ASC" inverse="true";
	
	BlogEntry function init()
	{
		variables.categories = [];
		variables.comments = [];
		return this;
	}	
}

js|
component displayname="BlogCategory" extends="Entity" output="false"
		  persistent="true" accessors="true"
{
	property name="name" type="string" ormtype="string";
}

js|
component displayname="BlogComment" extends="Entity" output="false"
		  persistent="true" accessors="true"
{
	property name="content" type="string" ormtype="text";
	property name="blogEntry" fieldtype="many-to-one" 
 	  	     fkcolumn="entryId" cfc="BlogEntry";  
}

As you can see, this is really a tiny amount of code when you consider everything that is going on under the hood. This gives me a solid basis for the application. I can create these objects, set properties and associations, and persist them to the database. But that's the easy part. I want to go further than the simple use cases. In the upcoming entries, I'll look at how to best handle the bi-directional association between BlogEntry and BlogComment, as well as how to automatically set the createdBy and dateUpdated properties in Entity. I'll also be taking an in-depth look at using HQL for filtering, sorting, and optimizing the way the objects are created to eliminate unnecessary database queries.

ColdFusion 9 Article at Techrepublic.com

Mon, 01 Mar 2010 11:25:00 -0700

Just a quick note that I've had an article on ColdFusion 9 published over at CNET TechRepublic.com. It probably won't tell anyone who reads my blog much that they don't already know, but I hope that it attracts the attention of those outside of the core CF community!

More on CF9 ORM Relationships

Mon, 21 Dec 2009 13:07:00 -0700

My entry late last week on association management methods prompted a number of comments. I was going to add another comment but this became quite long so instead I'm adding another blog entry. The point of my last post was to talk about bidirectional relationships, particularly a one-to-many/many-to-one between two entities. Hibernate (and, thus, the CF9 ORM) has the ability to specify an "inverse" attribute on your relationship. To better show why you usually want to do this, let's look at an example. [More]

Bidirectional Association Management in ColdFusion 9 ORM

Wed, 16 Dec 2009 10:36:00 -0700

And to follow up on my recent pledge to start blogging further about ORM, lets jump right into a recent topic. A thread on the CF-ORM mailing list brought up the topic of dealing with a bidirectional relationship. [More]

Iterator on RIAForge, and Updates to FormUtils and ColdSpring Utils

Wed, 16 Dec 2009 09:49:00 -0700

The blog has been quiet lately, but that should be changing now that I'm finally doing some real work with ColdFusion 9! In the meantime, I've committed a few minor updates to some RIAForge projects, and added a new one. The new project is Collection Iterator. This is simply a CFC that allows you to iterate the same way over queries, lists, structures, or arrays. The syntax is simple:


var array = ['foo', 'boo', 'zoo'];
var iterator = new Iterator( array );
var counter = 0;

while( iterator.hasNext() )
{
    counter++;
    var thisRow = iterator.next();
    assertTrue( array[counter] == thisRow, "Array element not found." );    
}

assertTrue( counter == 3, "Iterator did not loop the correct number of times." );

The obvious benefit is that it lets you handle all four collection types in a standard way. This is a CF9-only component, as it is written using the new script-only CFC syntax (which I LOVE, but will be talking about further in future entries). As for updates, I fixed a bug in the DynamicXMLBeanFactory, which is part of the ColdSpring Bean Utilities library. There was an issue when using ColdSpring configuration files that imported multiple other config files. The CFC was also modified to only attempt to do an ExpandPath() on the configuration file location if a file doesn't exist using the value supplied by the developer. I also updated the FormUtils CFC to make the constructor arguments optional, to make it easier to configure and use. So, that's all for now, but look for some entries on CF9 ORM tips and techniques, as well as a full reboot of my earlier series on the Swiz framework for Flex. Swiz 1.0 alpha was just released, and as the finishing touches are added I plan to be blogging about all the excellent new capabilities that have been added by the Swiz team!

My CFinNC Presentations at SlideSix

Thu, 22 Oct 2009 12:02:00 -0700

I've uploaded my CFinNC presentations to SlideSix for anyone who's interested: Object-Oriented Design Principles Introduction to Swiz Overall, CFinNC was great. I actually had to work for a large chunk of the weekend so aside from presenting and mingling with folks later in the evening, I didn't get to attend many other sessions. That said, everything looked top-notch while I was there. The conference unfolded very smoothly and all of the attendees seemed very engaged. Hats off to Dan Wilson and the entire volunteer team for pulling this off! This conference definitely held its own against the other CF conferences I've attended. It was very difficult to tell that it was completely free. Hopefully we can do it again next year!

On the CFPanel Podcast with Mark Mandel and Barney Boisvert

Fri, 04 Sep 2009 12:11:00 -0700

I'm happy to say I'll be participating in the CFPanel Podcast on September 8 at 8 PM EST. We'll be discussing ColdFusion and Java integration. I hope to add some helpful substance to the conversation, but I'm really looking forward to hearing what Mark (who created JavaLoader) and Barney (who created CFGroovy) have to say. Listen in if you can, or check out the Connect recording afterwards. Thanks!

I'm Speaking at the CFinNC Conference...See You There?

Fri, 04 Sep 2009 12:00:00 -0700

Just a quick note that I'll be speaking at the CFinNC conference on October 17-18th here in Raleigh, NC. My topics are Object-oriented Design Principles and The Swiz Framework for Flex. The conference is FREE and the lineup is very impressive, so if you can attend, please register! And if you register, please actually show up! The danger with a free conference is that it's easy for folks to back out at the last minute, since they lose nothing. But for the organizers, it makes estimating actual attendance difficult. So if you sign up, please do your best to make it. :-) I'm looking forward to seeing some folks that I normally have to wait until MAX or next year's CFObjective or CFUnited conferences to see. And I hope to meet a lot of new people as well. See you in Raleigh!

Final Prep for CFUnited!

Mon, 10 Aug 2009 13:07:00 -0700

It's been a while since I've blogged, as you might guess I've been really busy. I do plan to dive back into blogging again after the conference, both here and at the Alagad blog. But right now my focus is on wrapping up some tasks so that my time at CFUnited is used to it's full potential! I'm presenting on Friday on Introduction to Object-Oriented Modeling and Design. I've tweaked the presentation a bit since I gave it last, based partly on the podcast that Hal, Ben Nadel and I did a few weeks ago. If you're interested in what helps make "good" OO design, I hope the presentation will be helpful. Again, let me point out that the presentation isn't an introduction to OO, I'm assuming attendees already understand what a class is, what an object is, etc. This presentation is talking about OO at a more general level, in terms of how sets of objects actually work together. My tentative schedule for the conference is attached to this entry, so if you'd like to chat about OO, CF, Flex, Groovy, or just about anything else, feel free to catch up with me. I'll also most likely be a regular at any evening gatherings at the hotel bar. ;-) Anyway, I hope to see you this week in DC! Until then!

ColdFusion and OOP - Match Made in Heaven, or Long Road to Hell?

Tue, 14 Jul 2009 06:29:00 -0700

Hal Helms, Ben Nadel and I recorded a conversation over the weekend on the subject of OO in CF. I'm supporting the position that OO is still a good thing in CF, Hal disagrees, and Ben is undecided. As you might expect, Hal is left a trembling husk as the weight of my arguments unmercifully crushes him. You know those scenes in superhero movies where someone gets punched so hard they end up in a crater in the ground? It's like that. Only worse. In all seriousness though, it was a very fun talk and I think there are some solid points made from all involved, but I'll let you, gentle reader, be the judge. You can download the recording here. In the interest of keeping any discussion on this topic from fragmenting, we've decided to disable comments on our respective blog entries and instead created a Google Group to act as a central sounding board. Hopefully this isn't too inconvenient, I realize it's something of a departure from the norm, but let's see how that works. I'm not sure yet whether this will turn into any kind of regular discussion, but I suppose it could. We'll just have to see what folks think! Thanks.