Neptune 1.0 Beta 1 Documentation: Multi-Table Program

Neptune Information

Download from RIA Forge

Multi-Table Program

Based on Dan Wilson's "So you want to build a ModelGlue:Unity application (Part 4)" (and the CFWheels version).

We have our prototype list and form pages working now including basic validation. Being proud of ourselves, we show it to our client. He's happy that we have something done so quickly, but we find out that we have misunderstood what he wants.

He doesn't want a "Contact Type" text field. He wants a drop-down box with options "Friend", "Co-Worker", and "Enemy". We ask him if these options will ever change and he tells us "not very often" (which, of course, means that they might change and he might even decide to rename "Enemy" to something else later).

Now we are looking at a multi-table application rather than this simple single-table CRUD we thought we were going to do.

First, we should add the definitions for our to "ContactTypes" table to our XML:

<cfcomponent extends="com.sebtools.ProgramManager">

<cffunction name="xml" access="public" returntype="void" output="yes">
<tables>
	<table entity="Contact Type">
		<field name="ContactTypeName" Label="Type" type="text" Length="20" required="true" />
		<data>
			<row ContactTypeName="Friend" />
			<row ContactTypeName="Co-Worker" />
			<row ContactTypeName="Enemy" />
		</data>
	</table>
	<table entity="Contact">
		<field fentity="Contact Type" />
	</table>
</tables>
</cffunction>

</cfcomponent>

If we have fields in our form then we will also need to change the "ContactType" field in our form to point to the new "ContactTypeID".

<cf_sebForm CFC_Component="#Application.ContactOMatic.Contacts#" sendback="true">
	<cf_sebField name="ContactName">
	<cf_sebField name="ContactTypeID">
	<cf_sebField type="Submit/Cancel/Delete">
</cf_sebForm>

Now let's take a look at that form and see what we can see:

What Happened?

<field fentity="Contact Type" />

This line creates a field named "ContactTypeID" to get data from the ContactTypes component inside the main component. The form then uses the primary key field (assuming there is only one) as the value of the field and uses the field defined in the "labelField" attribute for the display in the drop-down.

In order for this to work, the Contacts component being used by the form and the ContactTypes component being referenced in the XML have to be children of the same component.

<data>
	<row ContactTypeName="Friend" />
	<row ContactTypeName="Co-Worker" />
	<row ContactTypeName="Enemy" />
</data>

This code defines data for the ContactTypes table. It is used by the simulated database instead of whatever random data it would normally generate.

Now when we show our new Contact-O-Matic to our client he is happy. Right now, however, this is just a prototype. It needs to connect to a real database to be useful.

Next: Using the Database