Categories
Contact Doug!
Learn About Doug!
View Doug Boude's online resume
updated 11/18/2009

View Doug Boude's profile on LinkedIn
Link to me!

Follow Doug Boude on Twitter
Follow me!

Be Doug's friend on Facebook
Befriend me!
(I promise not to follow you home)
OO Lexicon
Chat with Doug!
Recent Entries
You may also be interested in...
Web Hosting

<< May, 2013 >>
SMTWTFS
1234
567891011
12131415161718
19202122232425
262728293031
Search Blog

Recent Comments
Re: Disappearing IE Popup Window During Save/Open Dialog (by LZ at 4/20 7:58 AM)
Re: Create Dynamic WHERE Clauses in PHP (by pooja at 3/20 7:29 AM)
Re: Just What IS a 'Service Layer', Anyway? (by EugenK at 3/07 7:56 PM)
Re: Using Google as your CF Mail Server (by 5starwebteam.com at 2/25 1:27 AM)
Re: Why Provide for Service layer objects in CFWheels? (by Steven Benjamin at 1/25 11:43 AM)
Re: What is an 'Advanced' Coldfusion Developer? (by ColdFusion Developer at 12/24 5:14 AM)
Re: Equivalent of SQL "TOP X" in Oracle (by Ashenafi Desalegn at 12/06 5:29 AM)
Re: PHP Export to Excel Snippet (by serene at 12/05 1:44 AM)
Re: Just What Is 'Application Logic', Anyway? (by Arif at 11/13 8:06 AM)
Re: Hosts File Changes Not Acknowledged on Vista 64 (by Aaron at 10/22 2:31 PM)
Re: PHP Export to Excel Snippet (by Jafar Shah at 10/10 4:28 AM)
Re: Viewing Option Text (in IE7) that's Wider than the Select List (by Chenelle S at 10/04 12:53 PM)
Re: PHP Export to Excel Snippet (by Kilo at 9/26 5:20 PM)
Re: Porting Coldfusion Code to Mura (by tariq at 9/03 9:51 AM)
Re: Just What IS a 'Service Layer', Anyway? (by James at 8/27 4:06 PM)
Re: Calculating Business Hours (by helen at 8/14 2:54 AM)
Re: What IS 'Business Logic', Anyway? (by dougboude at 8/06 11:30 AM)
Re: What IS 'Business Logic', Anyway? (by Adrianne at 8/06 10:29 AM)
Re: Family Law: The Weapon of Choice for Woman Scorned (by dougboude at 8/04 4:39 PM)
Re: Family Law: The Weapon of Choice for Woman Scorned (by Lola LB at 8/04 7:43 AM)
Archives
Photo Albums
Funnies (5)
Family (3)
RSS

Powered by
BlogCFM v1.11

19 April 2011
Picking Up Where Interfaces Fail
Interface.CFC

What Is An Interface?

Interfaces in ColdFusion are something that makes most of us turn our heads sideways and give the two dollar look. Any of us who didn't come from other languages before ColdFusion probably hadn't heard of them, and since they were introduced into CF, the majority of us haven't taken the time to even understand their purpose, let alone actually use them for anything. Myself, I did take the time to know what they were for (in a ColdFusion context anyway), but even so had never found a single solitary use case for them...until recently.

For the record and to give the rest of this post context, let me share my understanding of what interfaces do for us in ColdFusion. In a nutshell, they act as validators for our CFCs. That is, by "implementing" an interface within a component (<cfcomponent implements="myInterface"....>), we are forced to adhere to rules we laid down beforehand for the functions we will write in the future, and we'll be stopped dead in our tracks if we violate any of those rules. Rules such as  what arguments a function must minimally have, what the returntype of a function should be, and other criteria that interfaces allow us to specify.

My Use Case

I have recently written a small library called JBase that is a virtual relational database. Two pieces of functionality that JBase sports, which I factored out into their own components, are data formatting and validation. Now, knowing full well that I haven't anticipated every possible formatting or validation need, I created those components in such a way that they can be easily customized by the developer, AS LONG AS CERTAIN RULES ARE FOLLOWED when writing the custom functions.

I documented what those rules are very thoroughly, as well as placing them into the CFC itself as comments. But, I really wanted to be able to make CERTAIN that all customized functions followed my rules. Now this, you might be saying to yourself, is a perfect use of ColdFusion interfaces! And you would be so very right if it weren't for a couple of teeny weeny challenges, challenges that caused ColdFusion interfaces to utterly fail in this scenario.

1) CF Interfaces (as it is in all languages to the best of my knowledge) require that you EXPLICITLY indicate the name of the function you want to police - but I have no idea what my developers will name their custom functions! As long as they follow a naming convention of "format[whatever]" or "validate[whatever]", the function has a valid name according to my rules.

2) ColdFusion interfaces do not allow me to police functions that are designated as private. Why, I'm not sure, but since one of my rules is that custom functions MUST be private, this was also a fail. What to do, what to do?

Write my own interface component.

What I needed was something I could transparently apply to a component or chain of components (if one extended the other to infinity) that would inspect all of the methods and ensure those whose names matched a pre-defined pattern also adhered to other applicable rules. I called it, strangely enough, "Interface.cfc". Interface.cfc leverages a "rules" configuration array that it uses to analyze the methods, public AND private, within a component or component chain that can be n levels deep. It allows me to provide a regular expression describing function names, and when it encounters a function whose name matches the regex, it then analyzes the function based on the rules associated with that regex. Here's an example rules config array:

<cfscript>
  stRules = [
  {
   name = "^format(?!Value).+?",
   args = {
    targetValue = {
     type = "string",
     required = "true"
    }
   },
   access = "private",
   returntype = "string"
  },
  {
   name = "^validate(?!Value).+?",
   args = {
    targetValue = {
     type = "string",
     required = "true"
    }
   },
   access = "private",
   returntype = "boolean"
  }
 ];
 return stRules;
</cfscript>

 

Allow me to share a short list of Interface.cfc's highlights:

  1. Very non-intrusive. Simply extend Interface.cfc within a component or within the most base component of any heredity chain;
  2. Rather than die on the first error encountered, Interface.cfc will analyze the entire function collection at once and throw a comprehensive error detailing EVERYTHING it found in violation of the rules;
  3. The rules is an easy to read array that is self-explanatory and highly expandable.
  4. Rules are triggered when a function name matches a regular expression in the "name" key for a given rule set.

 

 

 

That's it! Let me show you how to use it and then what the results look like.

Picture If You Will...

Here is a rough diagram of the components that comprise the JBase relational database library. I've circled the customizable components in red:

Here is the same diagram showing interface.cfc implemented to ensure that all of the rules I lovingly outlined in the documentation are actually adhered to :) :

In this diagram, the components circled in red are those who will be validated by Interface.cfc. If we had three or four or n components in the inheritance chain, ALL of them would be subject to Interface.CFC's scrutiny. (note: the level at which Interface.CFC's functionality is triggered does allow one to control "how high" up the chain validation will crawl. The level at which "validateInterface()" is executed is where validation begins to cascade downward. Typically, you will execute validateInterface() at the topmost level component in the chain.)

To use Interface.CFC, follow these simple steps:

1. Create the rules array within the getRules method of Interface.CFC;
2. Make the most base component in the chain (or the component being validated, if there's only one) extend Interface.CFC (<component extends="Interface"....>")
3. Execute the "validateInterface()" method in the pseudo-constructor area of the topmost component that is to be validated
liks so:

<cfcomponent extends="myBaseComponent">
 <cfset validateInterface() />
 
 <cffunction name="init" ....</cffunction>
 ....
</cfcomponent>

 

 

For demonstration purposes, I have chained together (via the "extends" attribute) three components with the most base of them extending Interface.CFC. My rules are defined as in the rules example above. I purposefully coded in several errors. When I attempt to instantiate the topmost component, here is a screenshot of the results:

That's it! I'm extremely pleased with the results.

You can grab Interface.cfc here. Get Interface.cfc from Github at: git://github.com/dougboude/interface.git  View the awesome API documentation here.

And Boyan Kostadinov (@boyank), my .NET evangelist buddy, time to eat a little crow pie my friend. I don't UNDERSTAND interfaces??? Wrong, my man. Dead wrong. Contrary to the beliefs that keep some programmers of other languages thinking highly of themselves, this stuff just ain't all that challenging to comprehend once you weed through all the highfalutin lingo, acronyms, jargon, and fluff. Literally, I can teach this stuff to my 4 year old (and have!). ;) Love you buddy.

Posted by dougboude at 12:18 PM | PRINT THIS POST! | Link | 4 comments



12 April 2011
JBase: The Virtual Relational Database Component

DISCLAIMER: My JBase project is in no way related to or in competition with a commercial relational database product called jBASE. Though my project remotely resembles jBASE only in that both perform data storage and retrieval, my project does so in a COMPLETELY different and very specific-context: ColdFusion. My product cannot and never will be able to compete with jBASE for market share. End of disclaimer.

My little pet project JBase is at a point now where I feel *okay* about letting people play with it, so I thought I'd let y'all know. For clarification's sake, JBase = Json Database, though the name is a bit misleading as the JSON portion of the code really plays a semi-minor role. In a nutshell, JBase allows you to define an entire database structure using CF's structure notation, including tables, fields, field metadata, and table relationships, and then work with that database via the JBase component as if it were an actual backend database. Since most apps these days sport a service layer between the backend database and the consuming application, you can think of JBase as a service layer object that accesses a database that lives entirely in RAM.

A few things about JBase that I think make it cool to work with (I built a sample app with it, and it was fun!):

  • JBase utilizes an ORM-like API that most users will be familiar with;
  • JBase's virtual database schema is configured by the developer using a Coldfusion configuration Component, making schema designs extremely dynamic and versatile (no XML!);
  • JBase is a Coldfusion Component, making it able to be used in the same way as any other CFC (controlled with IOC mechanisms, usable within caching schemes, injectable and accessible by other model components)
  • Although JBase exists as an instance residing in server RAM, it persists its data to disk and optionally reloads it from disk on instantiation, enabling data preservation across application restarts;
  • JBase is ideal for use within test-driven projects;
  • No DSNs to mess with!
  • JBase has built in data validation and formatting, both of which are easily customized;
  • JBase's API is robust, offering a lot of flexibility with implementation
  • JBase's child component JTable can be used standalone for smaller projects or to create your own virtual database manually!

If it pique's your interest and you've got a few minutes, you can access all of the docs (which I worked REALLY hard on!) and can download the project and a sample app at JBase.masonclaims.com

Let me know what you think!


If you don't feel like parsing through the docs right now, here's a presentation I did for my local CFUG
Posted by dougboude at 3:58 PM | PRINT THIS POST! | Link | 0 comments
06 April 2011
JBase Documentation Ready for Peer Review

The little open source project I've mentioned a time or two via Twitter is almost ready for release into the wild. All I have left to do is build a sample app that utilizes it and do a little more testing. BUT, I went ahead and did the documentation for it so that those who are curious can get a good feel for what the heck JBase even is.

Now, will JBase be useful to anyone beyond myself? I have no clue. But on the off chance that someone else might find it useful for something I want to make it available. I also do plan on pushing ahead with a version 2 since as I wrote up the docs I came up with a fairly long list of enhancements I want to add to it!

At the very least, working on the JBase project has given me a LOT of opportunities to refine my existing knowledge and learn a few new things as well. I've gotten to delve in depth into:

  • circular dependency
  • thread safety
  • object decoration
  • dynamic method generation
  • API and class architecture
  • Recursive functions
  • Component self-documentation
  • Component metadata traversal
  • Probably lots of other cool stuff I've forgotten at the moment

Without further adieux then, you can view the docs and download the code and sample app here.

Let me know what you think! And don't hold back...roast me if you find it to be justifiable. ;)

Posted by dougboude at 2:24 PM | PRINT THIS POST! | Link | 0 comments