Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at RIA Unleashed (Nov. 2010) with: Bob Silverberg and Carol Loffelmann and Vicky Ryder

Starting A Sample Project With An XML Database

By Ben Nadel on
Tags: ColdFusion

I have not been able to make the switch over to a real MVC type ColdFusion application architecture. But, I really want to give it a go. I am "learn by doing" type of fellow, and as a result, I am gonna try and build a small XML-database driven application. I figure using XML documents as a means of data persistence will FORCE me to really encapsulate things like data retrieval and data manipulation. Can you image putting XML parsing code all over the ColdFusion application??? Crazy!

So, now I just have to figure out how I want to go about managing data stuff. In past attempts to work with MVC, I have had Data Access Objects (DAO) that each call the database on their own. This is not possible at this point since there is no database. I guess I am gonna have to create another level of data abstraction that the DAO's can call.

Uggg, already my brain hurts :) But if I can figure this out, it's gonna be a sweet ass ColdFusion application.



Reader Comments

You may want to look into WDDX (and thus the cfwddx tag) for data storage. In one line of code you can convert a bunch of in-memory queries into an XML file. Sprinkle with a couple cflocks for safety, and all of your code should just magically work. Presuming, of course, that the QoQ engine handles the types of queries you are running.

But, it may also cause the universe to collapse in on itself. YMMV.

(I think I'm one of 4 people left on the planet that use WDDX. It's sad, really.)

Reply to this Comment

I worked on a bug traker (original built by a friend) that used WDDX for data storage. It was the original Lighthouse (no pro). What was nice is that you could drop it and run it - no db set up. What was sucky is that it slowed down like heck once you have a lot of bugs. ;)

Reply to this Comment

Rick, Ray,

I have not worked much with WDDX. My plan right now (and this is all in my head) is to create a DataService component. This data service component will be responsible for maintaining the XML files as well as in-memory ColdFusion queries. I haven't mapped it out yet, but I like where that is going as I can do all my locking in this component.

I figure the Data access objects will need to call functions on this service component like :

GetNewRecord( "tbltablename" )

Then set values on the returned structure, then call something like

InsertRecord( "tbltablename", objNewRecord )

This is going to start confusing me I am sure as the ideas of services, gateways, DAO, etc. already confuses me :) And now, removing a DB... forget about it... but heck, it's gonna be fun!

Then, I figure the gateways will have to get the cached queries and can only run query of query style calls:

GetTable( "tbltablename" )

Which will return a query object. Then the gateway can run off of that.

But this is all VERY preliminary. All in the head, none on the paper. We shall see how it goes.

OHH. but to get back to the WDDX idea... is there any advantage of WDDX over using a combo of CFXML and XMLParse and what not? I guess the WDDX will be small code, but I am hoping to abstract it out so that all the data storage is very simple and generic... something like:

<table>
<columns>
...<c name="id" type="INT" index="c1" />
...<c name="name" type="VARCHAR" index="c2" />
</columns>
<rows>
...<r>
......<c1>DATA HERE</c1>
......<c2>DATA HERE</c2>
...</r>
</rows>
</table>

The idea here is make as little code as possible. So, I am using "c" as the column definition node, "r" as the row definition node. I am also creating column aliases. So, the "name" column is actually "c1" in the rows. Again, all in the head right now. But I figure, I want to keep it really small. This might be a LOT of data even though it will be a fairly simple application.

I will keep you all updated, and would LOVE feedback.

Reply to this Comment

The primary advantage of WDDX is that it Just Works. You don't have to worry about escaping your data in CDATA sections, or proper nesting, or writing parsers, or anything like that. Like so:

<cflock name="UserFile" type="EXCLUSIVE" timeout="30">
<cffile action="READ" file="Users.xml" variable="wddxUsers">
<cfwddx action="CFML2WDDX" input="#wddxUsers#" output="qUsers">
<cfset QueryAddRow(qUsers)>
<cfset qUsers.Name[qUsers.RecordCount]="Aristotle">
<cfset qUsers.Password[qUsers.RecordCount]="sophistssuck">
<cfwddx action="WDDX2CFML" input="#qUsers#" output="wddxUsers">
<cffile action="WRITE" file="Users.xml" output="#wddxUsers#">
</cflock>

Otherwise, it's just another XML format.

-R

Reply to this Comment

Rick,

It looks cool. I just have to do some testing with it. Thanks for the example though. You know, I have read about WDDX a bunch of times, but I don't think I have ever actually tried it.

Reply to this Comment

Hey Ben,

Though this is an old post, given the latest advances with CF8/CF9, have you revisited this task and been successful?

I am looking at doing something similar. Build a "stand alone" web app driven by an xml reference file set. I will be utilizing CFWheels for this app and may either attempt build a cfc controller similar to your "Data Services" idea which will follow the Wheels ORM approach, or perhaps attempt to extend the Wheels Model to function with the XML "datasource" call.

Thoughts, or...., has someone out there already created a "plugin" which may do this capability leveraging ORM?

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.