This blog post began as a simple comment to Ray's blog post "Are We Falling Behind", but darn him, he moved me such that it turned into multiple paragraphs!

So, here's the commentary that the afore mentioned post and the thoughts of all its commenters evoked from me.

In My Beginning, There Was Procedural

In 2004 MX6 made a leap in evolution that opened the doors many native OOers had been waiting for, and they began to weave all sorts of new and strange CF tapestries. At that time, all of my CF coworkers were buzzing about "MVC", all the time, constantly; it was SO annoying! I was coding as I always had and didn't see any gaps in my ability to produce good stuff; I'd never used a CFC before and had no intention of starting at that time. That, coupled with the fact that I unequivocably tend to ALWAYS be wary of whatever direction the herd is heading (I've read about those caveman bison hunts!), kept me perfectly content just as I was. Fast forward to 2006. What was a buzz is now a dull roar. Fusebox has taken a quantum leap. Model-Glue, Reactor, Mach II, Coldspring...they are now incarnate and catching plenty of attention. My job at that time had me maintaining legacy code, so I spent my days tracing variables through myriads of includes, trying to find their origins...nothing that involved any new dev, for the most part. Then the directive came down to rebuild all this legacy spaghetti. Myself and two other team members were mandated to recreate this app, in a fashion that would allow it to be easily configurable, easily connect to multiple database backends, easily support multiple clients and THEIR clients, be easily skinnable, and have certain aspects of it be consumable as web services by corporate and other satellite offices. It was at that point that the ton of bricks fell and I knew that it would be a very bad idea to try and weave this masterpiece from scratch, so the team and I decided that "frameworks it would be".

At The Crossroads

Ah, but which framework should we choose? None of us had any experience with any of them; we had only read blog posts and accumulated rough ideas, foggy understandings, and enough theory to fuel lunch time discussions. To decide the matter, we architected out a small application with basic security and crud, and we built that app with each of the frameworks we were considering. What that accomplished was to solidify the vague understandings we had, and it let us find the framework that most suited our own personal development style (terminology, syntax, organization, etc.). Since that first app in Model-Glue, I have written several more using that framework and some others; but I have also written a decent number strictly "plain vanilla", simply because their scope was smaller than the problem a framework addresses. The beauty of things now, though, is: I have a choice.

I have to make a confession: the directive to build an enterprise-size app was not my only motivation to learn the frameworks; that was just my paid opportunity to do so. My stronger, deeper, and truer motivation at that time was that dull incessant roar I mentioned, the one that was always in my ear and eventually DID manage to make me feel like I was being left behind, professionally. Was I, or was it perception only? Well, if in my future job quests I continually find that I am unqualified for the position due to my lack of specific CF skills, despite the fact that I've been using CF for a decade or more, then I would have to say that yes, I WAS left behind. If I'm well able to procure suitable employment without having added that knowledge to my quiver, then no, I was not left behind. I don't have a good enough feel for the pulse of the CF job market to know which it truly is, nor am I any sort of prognosticator on this matter, but I DO know that I have absolutely zero regrets having invested the time in stretching my brain to accommodate both the old AND the new.

Change IS Scary, But Possible

Making the leap to this strange new world is daunting, without a doubt, and anybody who tries to tell you otherwise is doing that smoke-blowing thing. My own leap was still recent enough for me that I remember the doubts, frustrations, and pain of persistently banging my head against this apparent brick wall. But eventually, with enough experimentation, reading, experimentation and reading, it DID sink in! There was no shortcuts over that mountain, so I just took that first grip and pulled until I could reach the next one. As I learned things I blogged about them, leaving behind what understandings I'd gleaned in hopes that those following me could gain an easier foothold. But the simple truth with this is, as with every other thing in life that's worthwhile: if you want it, you can get it, but to get it, it is gonna cost you something. Accept this gauntlet, then take off running. I guarantee you, it is impossible to fail to learn OO in a CF context if you determine in yourself that you are going to do it. There's just too many people who have gone before you, no smarter than you are, who have managed to accomplish it; there's just too many fellow CFers who are able and willing to assist you along the way. You can't fail at this, should you choose to do it.

Opting Out: Is It An Option?

But what if you should choose NOT to do it? Let me preface the rest of this by saying that I do indeed love all my fellow CF developers equally, and I'd love to drink a pint with each and every one of you. But, just speaking from my gut, I believe that if you are not in a constant state of professional growth, which includes frameworks and OO methodologies, you will minimally eventually find yourself to be part of a CF minority, if not already. And I do believe that that minority will find itself at the lower end of a continually expanding income gap between those who made the time for this particular vein of professional self-improvement and those who did not.

I'm not condemning anybody for something they do not know (Lawd knows there's PLENTY that I don't know!), but what I am doing is encouraging one and all to take/make the time to get more than just an arm chair knowledge of what is happening all around you in the CF world; acknowledge that ever increasing dull roar of OO that you can't help but hear, and (in this case only), take a sip of this kool-aid. You will never regret knowing more tomorrow than you do today.

Doug out :0)

Yesterday I had the privilege of providing my first consultation job as an instructor on the subject of Coldbox. The team that hired me are at the stage in their project where they're ready to start writing code (database is designed, UML and usecase diagrams are complete, mockups have been created), and they wanted to "experience" my thought processes, the questions I ask myself, my approaches to implementing functionality, and how I troubleshoot as I make my way from an idea to a working app in Coldbox. So, we spent the entire day together building an app from scratch, using Coldbox.

In preparation for the task, I spent the past week investing a LOT of time re-reading the Coldbox docs, experimenting, building out a small sample application that the team and I scoped out beforehand, and making notes about my thought/decision-making processes along the way.

Taking notes about your own personal development process is actually quite interesting and insightful, and since my audience found it useful and enlightening, I thought I'd share a high level view of it with the rest of the community as well. What follows is a bullet point list of how I personally generally go from idea to app.

Let's take a walk in my head, shall we? Don't be afraid....

1. let's get the current version of the coldbox framework (www.coldboxframework.com)

6. Okay, now I'll take a first pass through my config.xml.cfm file and alter the settings I know about at this point.

7. At this point, I feel the need to go ahead and create my database table structure and get that to a solid starting point.

8. Let's tweek the default layout and make placeholders for the different components it must organize (header, footer, nav, content, messages, dynamic content area, etc.).

In a nutshell, this is my general thought process as I build an app, with emphasis on building a Coldbox app. How does my "to do" list match up with everybody else's? I'd be interested to know!

In case anybody wanted to attend but was unable, I just wanted to make it known that I did present at the Alamo Area ColdFusion Usergroup meeting tonight on the topic of the ColdBox framework. I was given 45 minutes, and finished precisely within my time limits, except for a few questions at the end that I had to field.

A link to the recorded presentation can be found at UG TV ( http://www.carehart.org/ugtv/ ), and is titled "A 45 Minute Discourse on the Subject of ColdBox". You'll have to try and overlook the slightly skewed sound and video tracks...just something we seem to have to live with when using Connect.

I am very interested to know what people think of the content, and any critiques that might help me improve my presentations in the future. With broad topics and limited time, it's hard to know where to focus sometimes.

Thanks!

Doug  :0)

The Scenario: My Coldbox/Coldspring/Transfer application has settings that I want to make maintainable via a user interface. Now, the Coldbox.xml.cfm file does make provision for me to add as many custom settings as I want to my app, but I don't want to require the end user to know how to edit this xml file (nor would I trust them to). I came up with a solution to this challenge that I'm really happy with, so I thought I'd share some snippets in case it proves useful to others.

Step 1 is to ensure that you have a table designed to hold these configuration settings. My database has a table named "configuration", with the fields ID, settingName, and settingValue.

The last item of business is to let Coldbox know that our interceptor exists. We do this by registering it in the <Interceptors> section of Coldbox.xml.cfm, like so:

Although ANYTHING you could ever want to know about coldbox is definitely in its documentation, I find that it is still necessary sometimes to have to piece things together bit by bit..."...line upon line, line upon line; here a little, and there a little:...." as the prophet Isaiah said... in order to fully comprehend them. In this post I'd like to share what I have distilled from the docs regarding the subject of using interceptors and custom interception points in Coldbox.

The Scenario:  you are building your first Coldbox app and you decide that you want to generate your navigation from your database only after the user has authenticated (before that, they get no nav). How we retrieve and/or create our navigation isn't relevant to this post (I'll likely be sharing my navigation interceptor in another post), but WHEN and WHERE creation occurs IS, so allow me to break it on down as I have come to understand it.

If you weren't already aware, an interceptor in Coldbox is simply a CFC with methods that can be executed anywhere in the Coldbox request lifecycle, independent of the logic you already have "hard coded" to run for that event. In terms that we can all probably relate to, think of interceptors in EXACTLY the same way that you think of application.cfc. You know that code within that CFC will run "just because the file exists" and you don't have to explicitly call it in your app. Methods like  "onRequestStart" or "onRequestEnd"...their code automatically gets executed at specifically defined moments in the request's lifecycle simply by virtue of their name and the CFC they happen to live in. Same with a Coldbox Interceptor, except unlike application.cfc, you have to tell Coldbox that your interceptor exists first.

It's important at this point that we briefly talk about interception points in Coldbox. You know what "onSessionStart" is, you know what "onRequestEnd" is, you know what "onError" is, etc. ... well take a gander at "preRender". This is an interception point built in to Coldbox that "happens", or is announced, before content is rendered as viewable. (On a side note, there are a whole lot of OTHER interception points that exist natively in Coldbox; you should take the time to read through the list of them in the docs before you start developing.) In order to take advantage of "preRender" then and make something happen at that point, I have to do three things:

1. Create an interceptor CFC and drop it into my "interceptors" folder in my Coldbox app;
2. Create a method in that interceptor called "preRender";
3. Register my interceptor in Coldbox's "coldbox.xml.cfm" file so that the framework knows it exists.
how to register a custom interceptor...

Okay, I said in my scenario description that I only wanted my navigation created IF the user was authenticated. Of course you can guess that my "preRender" method does a check to see if that has occurred or not, and acts accordingly. But, what about the actual login event itself? If you trace the process, the user will be authenticated AFTER the preRender event, and so even though they have successfully logged in, will NOT see the navigation! Not kosher.

I dealt with this by using one of Coldbox's "Custom Interception Points". At first, it seemed like such a  foreign idea that little ol' me would have the power to add an interception point within the request lifecycle. After all, weren't things such as "onRequestStart" items that only the framework or the CF Server itself had the privilege of manipulating? But here's where the mystique of interception points, even those used in application.cfc, went away for me. (Hopefully you are familiar with the children's game "Red Light/Green Light", because my understanding and explanation of an interception point is based on it). An interception point is nothing more than a framework or CF Server playing a game of "red light/green light" with our app. The call to the app (http://myapp/?event=index) is the little kid, running forward like he was told to do. At certain points, though, the framework calls out "greenlight!", and any bit of your code that you had set up listening for "greenlight" (containing a method called "greenLight()") executes, right there and then, independent of the code associated with the event being called, and even before the request itself has completed. In my case, then, all I did was write a bit of code in my login process that called out "onLogin!" as soon as authentication occurred. I then added a method to my navigation interceptor called...what do you think? Yep, "onLogin", that made sure the navigation was available for the user at the end of the request. Here, then, are the steps to adding and using your own custom interception points in Coldbox:

1. Tell Coldbox that you would like to use an interception point called "onLogin", or "onLogout", or whatever you want to call it;
2. Add a line anywhere in any of your handlers (controllers) that ANNOUNCES your custom interception point;
3. Create one or more methods in any of your interceptors named the same as your custom interception point.

That's it! Here are some code snippets of where and how to do each of the three steps above:

1. In coldbox.xml.cfm, in the "Interceptors" section, add a line like the following:

3. In your interceptor(s), create a method like so:

Doug out

In the first post on this subject, I shared my 10,000 foot view of what pieces needed to go where in a Coldbox app in order to implement security. A lot of the code in that post was probably unfamiliar looking to many people (I know it would have been to me a couple of days ago!). So in this post I want to share how I implemented Transfer and Coldspring in the security process, clarify what some of that code was doing, and whatever other details about it I may have also come to know.

I'm assuming that you already know what Coldspring is, what Transfer is, and the basics of an event-driven framework. For example, Coldspring is a framework that allows you to manage the relationships between your CFCs (CFC A needs a configuration bean injected into it, the configuration bean needs to be initialized with parameter X, etc.); Transfer is an ORM framework that stands between you and your database (in a good way) and lets you write your code "sans SQL"; and the basics of event-driven frameworks is that they have core components built into them that allow you (via the methods they expose to you) to reach into their very soul and leverage "core functionality", like retrieving global configuration settings, retrieve system beans, etc. Okay, all that having been said, here's the dialogue I had with my frameworks in order to get them all on the same page of the workbook (Personification to be followed up with real code snippets, don't worry. It just helps me simplify things when I animate the inanimate.  ):

1. "Hey, Coldbox;(via Coldbox.xml.cfm...) I'm using Coldspring to manage my components for me. What's that? You'll make your configuration settings available to Coldspring to use in its XML configuration file? When you fire up Coldspring you'll go through its configuration XML and replace any curly-braced variables with matching values from your own configuration BEFORE you initialize Coldspring? Aw, that's sweet. Thanks!"

2. "Hey Coldspring;(via Coldspring.xml.cfm...) I'm gonna need you to produce a few objects from our host MVC framework's core, Okay? What objects would those be? Oh, well, I'll be needing the Coldbox factory object since that's how you'll need to retrieve the rest of the framework's objects for me. I'll need you to ask the Coldbox Factory for an instance of the Coldbox framework itself since it has all the core methods that many of my model object will need; and I'll want a discrete instance of the Coldbox SessionStorage plugin as well so that my model objects can access my app's persistent scope. Let's see, what else...oh yes, I'll be using an ORM, so i'll need you to produce an instance of Transfer via its own factory. And then I'll just tell you about my model objects as I get them added to the app. Thanks, Coldspring! You're a real bud."

3. "Hey Transfer,(via Transfer.xml.cfm...)  I got a whole BOATLOAD of database objects I need you to make available to me. It's a very, very long list, so just read through it at your leisure."

My frameworks are very good listeners and so once I figured out exactly how to say what I wanted to say, they complied fully with my desires. So let's look at how I made them understand, shall we?

Dialogue 1
Within the Coldbox.xml.cfm file, in the <Settings> section, I made sure the following settings were like so:

Dialogue 2
We informed Coldspring of several different things, so let's look at them a chunk at a time.
"...produce a few objects from our host MVC framework's core...Coldbox factory object...Coldbox framework itself...a discrete instance of the Coldbox SessionStorage plugin...." Here is the XML to accomplish the previous:

 As far as the model, so far I have only one bean defined, and that is my "authenticationService" bean. Here's that Coldspring.xml:

 Dialogue 3
Transfer relies on an XML file to get its information about your database entities (tables) and their relationships to one another. I won't share the entire Transfer.xml.cfm file here since I've already got most of my entities defined for my app (long list), but here are the tables relevant to security:

 authentication handler

Okay, so our doLogin event is calling the authenticationService's 'login' method, passing in the username and password supplied; Let's look at authenticationService now.

 So, Transfer will create the requested bean and, if it matched the criteria passed in, the bean will be populated; otherwise it'll be empty, with a zero value for the primary numeric key ("ID"). After Transfer gives it back, I check the primary key. If it's zero, login obviously failed. If it's not, success! Stuff the user bean into session and return a boolean to the handler (controller).

I do hope you were able to follow this okay. I can't tell you how long I had to bang my head against it for it to sink in and gel, so I hope it saves someone else a few hours of digging through docs.

Doug out.

There's no denying it: the plethora of documentation and examples that exist for the Coldbox framework is invaluable and undoubtedly covers every possible scenario to one degree or another. As I press on into a project where the use of Coldbox, Coldspring, and Transfer has been mandated to me, I'm finding that, despite the documentation and tutorials, I'm still having to search around and piece together for myself some of the information I seek. So, to complement the existing volumes of Coldbox-centric information and for my own personal reference purposes, I'm going to post some of what I'm learning as it becomes coherent to me.  Tonight's post is focused on an overview of how to implement basic security in Coldbox using Transfer and Coldspring. I won't delve much into Transfer or Coldspring with this one (that post will follow soon) so that we can focus on the 10,000 foot view first.

As I mentioned, the first "block of functionality" I tackled was the implementation of security, so let's use that as our illustration. There is a lot of documentation on the subject and even a few example apps I found. But, the documentation left me with too much gray area as I attempted to relate what I read with my current level of understanding of the framework, and the example apps, though they worked wonderfully, didn't explain to me HOW they were working. I had to dissect the apps using my limited knowledge of Coldbox and painstakingly trace the event flow from one area of the framework and application to the next, referring to the documentation and even examining some of the framework's CFCs internally. The end result for me was the foundation for my own "flavor" of basic security implementation, and it this that I share.

First, my own visualization of the Coldbox event lifecycle. I realize that the true lifecycle in all its detail could consume many a diagram page, but for the purposes of someone simply desiring to add in a bit of functionality, I do believe I've illustrated all that is required.

A request comes in and right away Coldbox executes the interceptors it knows about. Interceptors are very aptly named, as they do just that: intercept the request before it gets too far and executes whatever methods are appropriate. In our case, we're interested in knowing right up front if the user attempting to fulfill an http request is authenticated or not. Intercept them, then, we shall.

Coldbox comes out of the box with a pre-built security interceptor (a CFC that is executed at what we typically know as the "onRequestStart" point), but being at the newbie point I am, I found it a bit too deep to assimilate. In order to understand how things really work, therefore, I created my own. I called it "security.cfc" and dropped it into my app's "interceptor" directory. The next step was to tell Coldbox that I have an interceptor in place. This is done in config/coldbox.xml.cfm, in the <Interceptors> section. Mine looks like this:

Let's assume the user is NOT logged in. My interceptor resets the current event to my login event, "authentication.login", and processes it. POP QUIZ: Based on the event name "authentication.login", what CFC and method within that CFC do you suppose Coldbox will be executing? I'm sure you guessed right, so let's go look at the 'Login' method within my 'authentication.cfc'.

Hmmm, where IS my authentication.cfc? It's not an interceptor...where is it? Ah, it's where Coldbox ASSUMES it will be (there's that "convention" thing again!): sitting in the "handlers" directory. We Model-Gluers and other MVC framework people might think of it more commonly as "controllers", but the Coldbox vernacular is "handlers", as in "event handlers". Here is the Login method:

Being the good controller/handler that it is, it's doing next to nothing except setting a few values in the event bucket and tossing some views into the view collection so that we can properly give the user a login form.

Now we see the login form, nothing fancy, just a prompt for a username and password. The user enters it, hits the submit button, and off we go to our form's action: authentication.doLogin .

Wanna see the "login" method in the model?

That's it in a nutshell! If I were me looking at this post two days ago, however, I would be very hungry to know the details of how I set up Coldspring and Transfer to play together, and how it is I am accessing my session scope and Transfer from within my model. In order to encapsulate the purpose of this post (give an overview of basic application flow for the purpose of implementing security), however, I shall end it here. But my next post will be the nitty gritty of how I wired all these pieces together.

Hope this helps someone, and do feel free to contribute your own wisdom to the comments!

ModelGlue:Unity - Modes of Operation

How to Toggle Modes

• change the "reload" property in Coldspring.xml to "true" for development or "false" for production;
• edit the "debug" property, setting the value to "true" for development or "false" for production;
• ensure that the "Mode" property in the Reactor bean definition is set to the value "Production" for production, or "Development" for development;

Refreshing During Development

Again, any additions or corrections that need to be made to this matrix, please shoot me an email (via my funky resume) or leave a comment (if you can pass the Turing Test).

UNDERSTANDING THE MODEL-GLUE EVENT LIFECYCLE

The Model-Glue framework can present an intimidating learning curve when coming directly out of the procedural world to that of Object Oriented Programming. One of the things that will help the Model-Glue student immensely is to have a solid understanding of how the Model-Glue event lifecycle works: being able to visualize the invisible. With this knowledge in pocket, many of the architectural questions that will inevitably arise will be more easily addressed. So, let’s explore what we mean by the term ‘lifecycle’, what the definition of ‘event’ is in a Model-Glue context, and what Event’s role is in a Model-Glue application!

 A Lifecycle You Already Understand

 Let’s look at a lifecycle you’re already familiar with: http request. Pictures are worth a thousand words, so allow me to illustrate this:

Looks familiar, doesn’t it? The request begins life when the client initiates it with an http call to our web server for a specific template. The server receives the request, grabs the template requested, and hands it over to the Coldfusion server for processing. The Coldfusion server renders the CFM template into pure HTML (since that’s all a browser understands), hands the HTML back to the web server, and the web server returns the HTML to the client. End of the request’s lifecycle!

 
When a client makes a request of a Model-Glue application, a similar process takes place. The focus of this post will begin (and end) at the point where index.cfm is requested and passed a parameter called “event” (eg; http://www.myMGapp.com/index.cfm?event=home). The receipt of this parameter is the first breath our Model-Glue application draws, and begins the internal process which we will now follow through to its conclusion.

What Exactly IS A Model-Glue Event?

‘Event’ is two distinct things:

• ‘Event’ is a simple value: a name, such as ‘home’, or ‘do.login’ (yes, compound event names are acceptable and even advantageous for organization’s sake!);
• ‘Event’ is a bucket.

 
 “A bucket?”, you may be asking yourself. Yes, a bucket! Buckets carry things around, and at a certain point in our event lifecycle study we will see how the event changes from being simply a name to an actual value-carrying OBJECT that gets passed around within the application! It’s a beautiful metamorphosis, as you will see.

 The Event Lifecycle in a Nutshell

Let’s begin with an overview of what takes place in the lifecycle of a Model-Glue event (We’ll be exploring each step in detail later):

1. A request is made, notifying model-glue to execute a specific event (eg; http://www.myMGapp.com/index.cfm?event=do.login). At this point, Model-Glue generates an empty Event Object (aka: bucket).
2. Model-Glue looks in its modelglue.xml file to find out what messages to broadcast to listening controllers ( <broadcast><message name="login" /></broadcast> ) for the 'do.login' event.
3. Controllers listening for the "login" message execute their corresponding functions ( <controller name="AuthenticationController" type="controller.AuthenticationController"><message-listener message="login" function="AuthenticateUser" /></controller> ).
4. Model-Glue executes any relevant result actions (behaves as an 'if' statement), if present.
5. Model-Glue renders any views that are defined for this event. HTML is delivered and the event lifecycle is over.

 
Event Lifecycle, Step One: Create the Event Object (aka: bucket)

 
The whole event lifecycle depends upon values being passed around within the application, so the first thing Model-Glue does after being notified which event to execute is to create an Event Object. Just visualize it as a bucket at this point.

 After the Event object is created, any incoming form fields and URL parameters are immediately stuffed into it for safekeeping.

 
Event Lifecycle, Step Two: Reading the Event Definition

 Now that Model-Glue has the Event Object all populated with incoming values, it’s time to discover exactly what should be done with them for the event name that was called. The instructions, or event definitions, that Model-Glue refers to when an event name is received all live in an XML document called “Modelglue.xml”. Here is what an event definition looks like:
 

Summary of steps 1 and 2

The <event-handler> tag has three children: <broadcasts>, <views>, and <results>, and they are evaluated in that order. Let’s look at each one more closely, following our Event Object through the process.

Event Lifecycle, Step Three: Giving Shout-Outs (aka: making broadcasts)

 The first thing Model-Glue does for a given event is to make any defined broadcast. A broadcast is simply a shout out that triggers certain CFCs to execute specific methods. In our example, the broadcast “login” is made. Model-Glue looks in another section of its Modelglue.XML file to find out what CFCs are “listening” for that particular message, then executes the relevant method. In this scenario, this is what Model-Glue found in it’s XML file:

 
Ah, so Model-Glue is going to invoke the “Login” method of the AuthenticationController.cfc (which lives in the “controller” directory). Here is an important thing to know at this point: for every method that Model-Glue calls, the Event Object that was initially created and populated will be passed in as an argument, like so:

 
Why? So that our methods can read values out of it (such as the username and password that were passed in via our login form) AND so our methods can put values INTO the bucket as well! In our example, the Login method is going to attempt to authenticate a user. If it succeeds, it’s going to add a ‘Success’ result to the Event bucket; if authentication fails, it’s going to add a ‘Failure’ result.

Summary of Step 3

Okay, the “Login” method finished, Model-Glue has the Event Object in hand, and there are no more broadcasts defined for this event, so let’s go on to the next step in the Lifecycle.

Event Lifecycle, Step Four: Decide What Results to Execute

 Take a look at the <results> section of the event definition. We see two named results defined (so called because each of them has been given a specific name): success and failure. Recall how our Login method added one of two possible results to the event bucket, either “Success” or “Failure”. At this point, Model-Glue looks for any results in the Event bucket and executes whichever one is appropriate. Executing a result really just means “hey Model-Glue, you found a result named “Success”, eh? Then I want you to jump to the defined event named “home” and execute that now.” If a result named “Failure” had been found, then the “login” event would have been called, presenting the user with the login form again. When Model-Glue executes a named result and jumps to another event, the programmer has two choices at this juncture. To start the new event fresh with an empty Event object, or to carry the existing, populated Object over to the next event. This is controlled with the <result> attribute “redirect”. If set to ‘True’, a new, empty Event object is created; if set to “False’, the original Event Object is passed along.

Summary of Step 4

At this point, all of our messages have been broadcast and relevant methods executed; if we needed to redirect to another event, that was also already accomplished. We’ve now arrived at the final step in the event lifecycle: Render our HTML and send it back!

Event Lifecycle, Step Five: Render The Views!

(aka: create the HTML that will be passed back)

 Since our “do.login” event was all about actions and not views, let’s look at the “home” event that a successful login attempt redirects us to:

 This particular event doesn’t ask Model-Glue to make any broadcasts nor does it ask Model-Glue to look for and process any results. What it DOES do, however, is ask Model-Glue to render two different CFM templates, dspMainContent.cfm and dspLayout.cfm. There are several important things to note here.

 First, that we can tell Model-Glue to render any number of individual CFM templates. Second, notice how each template is given a “name” attribute…the rendered HTML will later be referred to by this name. Third, the order we list them in is irrelevant with one WHOPPING exception: the last template rendered is the ONLY one that Model-Glue will return to the browser. So what happens to the other Views that were rendered and placed onto the Viewstack (notice how I just increased your Model-Glue vocabulary ;) )? All other rendered templates are “included” in the final template, in nearly EXACTLY the same manner as using a CFINCLUDE, only slightly different. See a previous post I did on Views called “Model-Glue Views Demystified” for more detailed information on this topic. Now, let’s find out where our Event Object/Bucket is relative to the views that are being rendered, shall we?

 Model-Glue makes the contents of the Event Object available to your CFM view templates in an object referred to as “ViewState”. It, too, is an object, very similar to the Event Object, and it contains all the values that your template could possibly need. You may be asking yourself, “why do we need the ViewState Object if we already have a perfectly good Event Object?”. Valid question, and the answer lies within the philosophy of object oriented programming and the two cardinal virtues that a framework like Model-Glue seeks to uphold: Encapsulation and Autonomy. Suffice it to say that in order not to violate basic MVC principles, copying the contents of the Event Object into the ViewState Object was the better thing to do. Okay, take a look at the following two lines of code taken from within a view template:

 Any CFM template created for use within a Model-Glue application can absolutely count on the presence of “ViewState”. The value “firstname” that we’re retrieving from ViewState is a value that was placed in the Event Bucket at some point previously in the event lifecycle, likely by one of our broadcasts. Are you seeing the beauty of the Event Object yet? From the beginning of our event call, that bucket was passed around here and there, values being put into it, redirections being made as needed, until finally we arrive at our views where all of the previously saved values are made available for use within your templates. Strings, Arrays, Structures, Queries, and even other Objects can be stuffed into the Event Bucket and made available via ViewState. No limitations in that arena!

Slightly off topic from this article, let’s quench some curiosity and sneak a quick peek at how the final view being rendered includes content previously rendered in the viewstack, in this case, how “body” is output within “final”. Take a gander at the following few lines of code:

Yes, it’s really that simple. All rendered views are placed onto the viewstack, referenced by the name we gave them in the event definition, and are available within our template by accessing the “ViewCollection”.  Again, for more detail on Model-Glue views, see the “Model-Glue Views Demystified” post.

Views all rendered and the final HTML complete, Model-Glue returns it to the web server, which in turn returns it to the browser that requested this particular event in the first place.

Summary of Step 5, and the end of our Event Lifecycle

This is the end of our Event’s life; it is disposed of properly. RIP.

 
One Final Bit of Trivia

If you’re curious about what the Event Object really looks like, here’s a CFDUMP showing it and its methods:

CFDUMP of the Event Object

Conclusion

 As its name implies, Model-Glue is a framework that allows a developer to create code that is truly self-contained and reusable by acting as the glue that binds all the pieces together. It accomplishes this by managing the one common denominator that the Model, View, and Controller all have in common: The Event Object. From the client’s initial call to the final delivery of the requested HTML to the browser, it is the Event Object that the developer must understand and interact with in order to create a working application. Only a mid-level understanding of the event lifecycle is required to meet the majority of architectural needs. How to incorporate security, how to ensure the display of appropriate navigation, how to easily add in new functionality: these are all common challenges that understanding the Model-Glue event lifecycle will enable any developer to overcome.

1. make sure they typed their password in twice the same way,
2. and make sure their email isn't already used in the system

1. add a method to your customizable validator CFC for the target table;
2. add a 'validate' method to the same CFC in order to overload the system version of the same;
3. within your custom 'validate' method, execute your custom method first
4. within the same, execute the system version of validate using "SUPER.Validate()"
5. edit your dictionary file to add a translation for your new custom error

(Consider hiring Doug to instruct you and your team in the ways of OO!)

I've been hearing the term 'Service Layer' everywhere for at least the past year and a half, as I'm sure most of my peers have as well. Whether it's seen in blog posts, heard during casual conversation at conferences, found in articles, or woven throughout almost any discussion at all concerning OO and Coldfusion...the term is quite prevalent and common these days. But I had a problem: the term held absolutely ZERO connotation in my mind. No picture was ever conjured up when I came across it, no corresponding 'Doug Boude' translation was found in my internal lexicon; I felt quite out of the loop. Ah, but recently that has all changed, as the phrase itself has not only come to life for me, but found an absolute and permanent place in all that I do, technically speaking; an epiphany, if you will.  I just figured there were others out there who, like myself, may still be kinda grasping for a way to think about the term, so what follows is my personal definition/explanation of what a Service Layer really is. Please feel free to append, addend, flip, and twist it to your heart's content until it's as whole as it ever can be.

SERVICE LAYER

This is not NEARLY as gray and ambiguous a term as you might think. Picture if you will, a man sitting comfortably on his sofa. In one hand is the remote for his very large plasma TV; in the other hand is a remote for his home theater system. The two remotes and the man are all objects, and all three come pre-built with things they can do. In the kitchen is the man’s wife; let’s think of her as the calling application. She barks out the order to the husband object, “START THE MOVIE, YOU IMBECILE!”. The husband object just happens to have a startTheMovie method, and begins to execute it. First, he manipulates the objTVRemote object, calling its “tvOn” method. Then, he manipulates the objDVDRemote object, calling it’s “dvdOn” and “dvdPlay” methods. Now he manipulates the objTVRemote again, calling the “inputSRC” method and switching the tv to receive the dvd input. Tada! Movie is playing now!

Pretty clear scenario, eh? Well, in this illustration, the MAN is acting as the SERVICE LAYER. Although he has a “startTheMovie” method, all he’s really doing is coordinating efforts between other lower level objects that actually do the work. His wife doesn’t care about the remotes or how they work, and her life is then simplified because she need only make her one call to her SERVICE LAYER OBJECT and he handles the nitty gritty details. Service Layer…not such a deep, complicated mystery after all, is it?

Doug out.