Yesterday we looked at how to setup a login form and process the information with ColdBox. Today we'll go a step further by viewing the code behind the authentication model.
Now that we know what we're working with, we're going to need to sit down and understand how our users will be defined and how they will authenticate with the system.
So what does Coldspring do, anyways? We know by now that it's an Inversion of Control (IoC) framework. We also know that it helps us manage dependencies between objets. And yet, we're not quite sure what that means exactly yet. To help demonstrate the power of Coldspring, I've prepared a simple example.
Now that our application is setup, we want to make sure that it works. We'll start out by removing extra files we won't need. Once that's done we'll setup our default event and make sure everything's working.
Last week we were talking about using ColdBox and Coldspring to run our project. Let's take a look at how we actually make this happen.
Two days ago I had announced that I'd started work on a new project that I'd been wanting to work on for a while. Rather than spill out all the details in one post, I thought it'd be better (and funnier) to stretch it out a little.
Earlier today I blogged about being aware of the differences between the way ColdBox and ColdFusion 8 handle variable names when serializing to JSON for remote calls (the original post name is much more elegant, I promise). Several questions arose as to the different ways variables can be created and how exactly each method would output, so I decided to put together this short test.
Nothing big, really. However, I did spend part of the morning figuring it out. If you follow me on Twitter, you might've noticed I had to work out a weird problem with ColdBox and jQuery. What was happening was that I had a jQuery plugin working great with CF8, but as soon as I started using it on an app built around ColdBox it stopped working.
Last night I had a little time on my hands and decided to start a project I'd had on the backburner for a while (hint, hint). While setting up Coldbox, I wondered: Why not use application-specific mappings to reference the right framework versions? You might remember I had made a (short) series on refactoring Coldbox, Coldspring and Transfer for this exact reason. However, reading the Jedi's Transfer adventures made me realize that being on ColdFusion 8 meant that I could have these specific mappings, rather than refactoring the frameworks. I ran into an issue or two, however, and here's how I got rid of them.
Last week, I showed you how I had setup my register method in my project. After a couple of comments, I realized I had tied my service layer too tightly with my MVC framework (ColdBox), by passing in the entire event object, rather than just the data that I needed. Today, I explore a different way of doing things, while also making a couple of little changes to the way the handlers are setup.