Posted By : Dan Wilson     February 4, 2007 1:25 PM

In the next few series, our Contact-O-Matic will persist data in a database. The queries and relationships are simple and should translate over to any database. Our code will be organized into two types of components the DAO (Data Access Object) and the Gateway. These two components are common structures used in many Object Oriented systems and a quick google search will land you on endless descriptions for each. For our purposes, all we need to know is the DAO and Gateway will help us organize our code into sections. The DAO is for pulling back a single object, the Gateway for a query of objects.

Another architectural feature of our Contact-O-Matic is our ContactService.cfc component. Service components help tie your other components together. Note how simple it will be to add in new database functionality.

At the end of series 5 of our Contact-O-Matic, we had a ContactService component which returned the ContactType data , a single contact object and a list of contact objects. Even though we are going to add a DAO component as well as a Gateway component, they will be tied together within the service component.

Some of you might be asking yourselves why we have all of these components. After all, there are huge and complex ColdFusion applications written without a single component. Couldn't we just put our queries in the Controller and be done with it? That is a very valid question to ask. You should be proud of thinking of it. Question Everything!!!

The main point of these separations in our code is to isolate variability. Meaning, when the application needs a feature, or a new data column, the affected sections in our code are compartmentalized and perhaps only one section of code needs to change in order for the entire application to be upgraded with the newest feature.

The complete source code up to the end of series 5 is attached to this article. It will be easier to follow along if you use this code.

A few quick notes before we begin:

1. Remember that the application files will be cached if the ModelGlue reload setting is 'false'. Any changes to Controllers, components created with ColdSpring, or stored in the Controllers will NOT change until you reload the application. This trips me up sometimes and my first step is to ALWAYS reload the framework
2. The <include /> tag is processed by BlogCFC as a cfinclude. Thus, whenever I paste in an event-handler section with an <include tag, I always have to use the entity symbol '& lt;' or i'll get an error when I post it. I try to leave a small note at the end of the code block about changing this in your code. If I forget, just know an XML tag will never actually start with '& lt;'
3. I am writing this tutorial with MSSQL server (delete derogatory note about Microsoft Products). Your database might have a slightly different syntax and I trust you to convert it over

Lastly, our database will have two tables:

Without further ado, let us get to the next piece in our Series, database support.

Download

9196 Views Print Comments (0) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 30, 2007 10:53 PM

I am planning out the next few steps in our ModelGlue:Unity series and would like to tally a vote. Currently our Contact-O-Matic is barebones. We went over how to use portions of ColdSpring to manage our service and to pass in configuration parameters. We also went over adding ModelGlue results to change the programmatic flow of the application. Following this pattern, you should have a good base on ModelGlue:Unity.

However, apart from the tabs, it has a plain-jane look and feel. Heck, it doesn't even save the contacts for very long ;). Before all is said and done, we will add in database persistance, security, the Transfer ORM and some Ajax.

We are going to need to put database persistance really soon as it is keeping us from our larger goals. After that, there are three different paths we can go.

In the spirit of Choose Your Own Adventure ( man, I loved those books ) which would you rather we tackle next? The choices once again:

1. Easy MG:U Security
2. MG:U scaffolding with Transfer ORM
3. Ajax Enhancements

Also, if you are following along with the series, please leave a comment or send me an email with the database you use on your development server. I am going to make an effort to be as cross-DB as I can....

7519 Views Print Comments (5) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 26, 2007 8:20 PM

Previously in this series, we installed the ModelGlue:Unity framework and the ColdSpring framework. We used the ModelGlueApplicationTemplate as the skeleton, added our basic flow and navigation. We can save and list contacts and our validation is working nicely,

In this section of our Contact-O-Matic, we will pull out the contact types values from coldspring and used them to add defined categories to our contacts. In a previous segment, we added the Contact Types as a 'map' in ColdSpring, now we will pull out the values and add them to our form.

[More]

9162 Views Print Comments (1) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 22, 2007 8:22 PM

Previously in this series, we installed the ModelGlue:Unity framework and the ColdSpring framework. We used the ModelGlueApplicationTemplate as the skeleton, added our basic flow and navigation. Finally we can save and list contacts Our Contact-O-Matic is moving right along.

In the last segment, we tested the 'failure' path and were routed back to the form. We also tested the 'success' path and were routed to the contact list. Open the ContactFormBean.cfc located in *ContactManagerMG/Model and edit the validate function (You did check the validate box in the rooibos generator like the last series said, didn't you ;) )

Our validate function should have the returntype of boolean. We will pass in a structure to hold any error messages and check the lengths of our two properties ContactName and ContactType. Your validate function should look like this:

[More]

10299 Views Print Comments (4) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 21, 2007 7:41 PM

Previously in this series, we installed the ModelGlue:Unity framework and the ColdSpring framework. We used the ModelGlueApplicationTemplate as the skeleton then we added our basic flow and navigation. Our Contact-O-Matic is moving right along.

In this segment of our regularly scheduled programming, we look a bit deeper into ColdSpring, add the contact form and contact list.

[More]

Download

23197 Views Print Comments (12) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 21, 2007 1:33 PM

Previously in this series, we installed the ModelGlue:Unity framework and the ColdSpring framework. We used the ModelGlueApplicationTemplate as the skeleton for our new Contact-O-Matic 1.0 alpha (don't worry, we'll eventually make this a Web 2.0 application). We rejoiced when we ran our application and now will look at some essential information about our new set-up.

Let's begin with opening the Application.cfm file and giving our application a name. Set the name attribute of the application tag to 'ContactManagerMG'. If for some reason, you already have another application on your server with the name of ContactManagerMG, put another name here.

Next, as ModelGlue uses ColdSpring for configuration, let us look at some key sections of the framework config. Open the *ContactManagerMG/config/ColdSpring.xml file in your editor. There are two beans defined by default, one with the id of 'modelGlueConfiguration' and one with the id of 'reactorConfiguration'. The 'reactorConfiguration' bean is for yet another framework you could use with ModelGlue. We won't need the 'reactorConfiguration' for this series and you may delete that bean from your ColdSpring.xml file.

Ok, now look closer at the 'modelGlueConfiguration'. The property tags define how your application will behave.

[More]

15622 Views Print Comments (6) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 19, 2007 9:13 PM

In this series, we will create a ModelGlue:Unity application. Our example application will manage contacts. We will start with a blank canvas and by the end of the series, have a functional application.

Lets begin:

Firstly, you should have the ModelGlue:Unity and Coldspring framework installed. If the framework is not installed, have a look at this post.

Our application will reside in a directory just under the webroot. We will access our application at http://LocalHost/ContactManagerMG. With that in mind, lets open the ModelGlueApplicationTemplate Directory.

This directory serves as an application skeleton for which to begin a new ModelGlue:Unity application.

There are two ways to get a new application up quickly. The first way is to copy the contents of the ModelGlueApplicationTemplate into a new directory just under your webroot called ContactManagerMG. Do a find and replace on 'modelglueapplicationtemplate' and change it to 'ContactManagerMG'.

The second way assumes you have cfeclipse or some other ANT environment. The directions below are specifically for cfeclipse.

Inside the ModelGlueApplicationTemplate directory is a file called build.xml. Build.xml is an ANT script. ANT scripts are sets of commands used to perform file and directory tasks. There are certain parts of the ModelGlueApplicationTemplate that need to be changed to our application name ( ContactManagerMG ).

We will now make the modifications to the build.xml file for the purpose of creating our new application.

Open the build.xml file. On a default install of ModelGlue:Unity the file will look like so:

In plain English, the build.xml file will copy the contents from the 'source' directory and place them into the 'target' directory then replace each instance of the 'token' and replace it with 'value'.

Make the following changes to the file and then run it.

IIS

Apache

Once your edits are complete, save the file and locate it in the navigator. Right click on the file and choose Run As -> ANT Build. You can see the progress in the console. Assuming no errors, you now have a new ModelGlue application and can begin coding.

Via Find and ReplaceANT build, you now have a new directory called ContactManagerMG. Run this in your browser and you should get a page showing the following:

Model-Glue 2.0: Unity

Voila. A new ModelGlue:Unity application. In the next series, we will add some functionality to our application.

15739 Views Print Comments (4) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs

Posted By : Dan Wilson     January 19, 2007 9:09 PM

ModelGlue:Unity is a ColdFusion framework that comes with a lot of of functionality and power right out of the box. In this tutorial, we will download all of the files needed to install ModelGlue:Unity, set up the framework and test our configuration.

ModelGlue:Unity requires the ModelGlue framework as well as the ColdSpring framework. We begin by downloading each part then placing them under our webroot.

You can find the latest builds in zip file format at of ModelGlue:Unity at http://svn.model-glue.com/trunk/modelgluebuilds. Select the most recent build and save it in a folder.

Update: Make sure the version of the ModelGlue:Unity framework is at LEAST version 284.

You will run into errors if you use an earlier version of the ModelGlue:Unity framework.

You can find version 284 here. A complete list of builds is here. Note the builds are sorted alphabetically so if you want the most recent, pay attention to the LAST decimal number. I.E. modelglue_2.0.284.zip is a later version then modelglue_2.0.52.zip even though it appears above in the list.

Next, download Coldspring 1.0 into the same directory.

Update: These instructions assume you will have both frameworks in webroot.

Placing frameworks in webroot is standard and preferred practice. If for some reason you MUST place the frameworks in a directory apart from webroot, you will need ColdFusion mappings for ModelGlue and for ColdSpring. There are few good reasons to install the frameworks in a directory other than webroot. If you have a good reason to do this, then you know who you are and what to do about it.

Now, unzip the contents of modelglue_2.0.xxx.zip underneath your webroot. When complete, you should have 4 directories direct children of your webroot.

1. documentation
2. modelglue
3. modelglueapplicationtemplate
4. modelgluesamples

Next, unzip the contents of the coldspring.zip file underneath your webroot. When complete you should have a directory called ColdSpring as a direct child of your webroot.

Verify the directories were created properly then run http://localhost/modelglueapplicationtemplate

If everything has been installed correctly, you will see:

Model-Glue 2.0: Unity

15939 Views Print Comments (1) Rapid Development, ColdFusion, Tutorials, Model-Glue

del.icio.us Digg It! Linking Blogs