OO ColdFusion Presentation Today on ColdFusion Meetup!

This is a late post, but I wanted to mention that I'll be presenting my Common Sense Approach to Object Oriented ColdFusion, 2010 Edition presentation in a few hours to the ColdFusion Meetup, 12pm Eastern (UTC/GMT-4) today. This is a slightly refined version to the one I presented in April at the CFObjective conference.

Watch Live Here

After the presentation, you'll find the recording posted here. I'll update this post after the fact with the direct URL.

Also, I'll finally be making the code from the CFObjective/Meetup for public view for the first time following the presentation, as well as post it on RIAForge and Github. One of the sample applications is the most extensive LightFront example posted to date, so this presentation should also show you a little bit on the framework as well. In that sample, there's also an "old school" version, as well as an unfinished Mach-ii/ColdSpring version that I'll continue to work on (but there's enough there to show the stark differences between a typical OO CF application and a simpler OO LightFront one).

I'll also be releasing a new version of LightFront (0.4.5) today as well.

UPDATE: The recording of the presentation can be found here:


Note: It went a bit long... 1:53:02

The code I show and the slide deck in the presentation is available via Subversion here.

To download a zip file, which has the code, PDF and PowerPoint of the presentation all in one, just go here:


LightFront - New Video Series - Getting Started with LightFront

I am starting a new series of videos that will also be carried on the CFConversations feed for my new LightFront. This first video is a Getting Started. In just a few minutes, I'll leisurely set up a LightFront skeleton application, and I'll spend the rest of the video showing you the Model, View and Controller within the skeleton.

LightFront even gets easier than this! I'll save that for the next video!

Update: Some people are reporting issues seeing the entire screen on this video. If you are seeing the same thing, you can view the video here by opening up a window.

Click here to view the video

LightFront 0.4.4 has been released, and... my CFObjective talk...

I've FINALLY released LightFront version 0.4.4. With this version, despite the version number, I am officially deeming this version of LightFront production ready.

Why did it take so long? I've spent a number of months on building a LightFront application, and I had to get that application out the door before I could spend time updating the framework.

That is both a detriment and a blessing. Sean Corfield's FW/1 framework, which started out very similar to LightFront, has been developing a big following, and that just proves that the lightweight framework idea we both had at about the same time had something. However, there's been a lot of work going on with FW/1, and LightFront's been quiet.

It really hasn't been quiet, though. As I said, I've been out there, using LightFront, and I've figured out lots of ways to use the framework and learned ways to be more flexible. While doing that, I also discovered something rather important about Object Oriented ColdFusion that fits right into LightFront. I also figured out some of the potential pitfalls you could run into while using the framework that all revolve around trying to work around the simplicity and trying to be "too clever", trying to do too much. This really had nothing to do with LightFront, but instead dealt with my own pitfalls with the model - the OO.

I'm not going to go into it more right now... this is just a teaser!

As FW/1 has built a following, it's also started to diverge from the direction LightFront is going. Both frameworks are still quite similar, but I definitely do see big differences in how we deal with views, and LightFront's push towards greater flexibility, especially with existing applications, over opinionated software development. The philosophy's different. I've made a career being able to make things work that other people couldn't, or couldn't as easily, so my tendency is to figure out a way how to do something instead of saying that's not how you do something and leave it at that. Rather than giving an opinion, LightFront gives you a chance to form your own software opinions using the framework. That's not, in any way, a slam on FW/1 or trying to say that LightFront is better. It's just different.

Although it's production ready, the documentation and how-tos need a lot of work, and the meetup I did several months back could have been a lot better. My hope is that my schedule will continue to be light enough so I can start making some strides toward building the docs and making some screencasts, and doing another meetup or two.

There are a few people using LightFront, too, besides me. Unfortunately, they aren't bloggers, so you probably won't hear much out of them, at least for now. However, they are very enthusiastic about LightFront, just like I am, and see its potential.

I think LightFront's turning out to be the framework I wanted, but I've got to spend more time showing that to you.

To those who have asked, yes, I am doing a presentation on my Object Oriented ColdFusion talk on the meetup soon. Unfortunately, thanks to scheduling conflicts, it won't be until June. With that, there is a new sample app that has been written three ways: One that shows spaghetti code, one that's a Mach-ii/ColdSpring version, and one that's a LightFront version. I've got a little bit of cleanup left on that, now that 0.4.4 is out, and I'll post the code once it's cleaned up. However, here's that presentation:

Vote for me to speak/open mike podcast at CFUnited!

I'm hoping to do a CFConversations Open Mike at CFUnited this year... but I need your help to get on the schedule.

I'll be at CFUnited regardless (well, hopefully; I'm planning to be there), but I'd like to have a big audience for one of the podcasts.

You can vote for the open mike here:


I've sent in a total of four topics, including one on LightFront, that could all use your vote:

  1. CFConversations Open Mike
  2. Improving Website Performance in the Browser
  3. LightFront - The CFML Framework that you don't need to be a rocket scientist to use!
  4. Object Oriented CFML: 2010 Edition

RE: CFConversations - I probably won't get another podcast out until March, as I'm pretty swamped with work right now until the end of the month, but I've got a few episodes coming, including a few guest interviewers, and two that are already recorded. I have to hit it hard in March, as CF Hour() is about to lap CFConversations. :( I'm all about healthy competition. :)

CF8 Cumulative Hotfix 4 is out... and LightFront continues...

It's been a while since my last blog post, so I thought I'd kill two birds with one stone, so to speak, as this post has two subjects. I'm terrible about blogging! :) I figured I could get this one out quickly so here goes!

Subject #1: LightFront development continues...

My last posting was on LightFront back in October. Don't take that to mean nothing has been going on with LightFront... it just means I've been too busy these days to blog much! LightFront has received a lot of updates since that post, and I even did a presentation on it for the CFMeetup: http://experts.na3.acrobat.com/p15958860/. That was back around version 0.4.0. I now have 0.4.3 in a branch, which is fully functional and feature complete (for 0.4.3, not for everything that will go into 1.0.0), but example 2 hasn't been brought up to speed yet. I hope to get to that in the next couple of weeks after I complete a project that's taking all of my bandwidth these days. 0.4.3 brings in full support for the model with the new initService() and initComponent() functions, as well as the new callAction() that will replace callEvent() in the next release, and loadAction(), which allows you to load an action into the request scope instead of outputting it directly. It's a great leap in the framework, despite the version sounding like it's a point release. If you've been using LightFront, make sure to start using callAction() instead of callEvent(), as callEvent() will be deprecated in 0.4.4 and removed in 0.5. This is in reaction to Joe Reinhart's comment in the previous blog entry, and I do agree that "event" portrays LightFront as an event-driven framework, which implies implicit invocation. There's nothing implicit about LightFront, and that's because you call your actions directly (explicit invocation). If you're looking at LightFront for the first time, use 0.4.3, which you can get at RIAForge (see link above).

Subject #2: A new CF 8 cumulative hotfix is out...

A mystery still present in the Adobe CF space is how word gets out on hotfixes and security updates, which don't always get the publicity they need to get them out into the public. Though I'm a registered CF8 user, I never get any emails from Adobe on these, and I wish that would change.

I got word of this one in, of all places, a Google alert. I thought I'd pass it on.

Adobe has just released cumulative hotfix #4 for ColdFusion 8.0.1. You can find more information about it here:


LightFront: The incredibly simple & approachable MVC Framework for ColdFusion

I'm finally blogging here about my new MVC framework, which I call LightFront. I first published it on RIAForge on August 31st, and I finally made the project publicly available on RIAForge on October 1st, with updates almost every day since.

I'm not at MAX this year (sorry no CFConversations episodes from MAX this year), and it's been a bit difficult for me to get out a podcast at the moment (a logistics/timing/personal issue... not worth discussing here, but I have two episodes almost out the door), so I thought it was time to post a blog entry about LightFront here.

First, here's where you can find it, and find out about it (beyond what I have said below):

LightFront is an MVC framework for ColdFusion. What, another one? Yes, another one. This one's a little different than the rest, although it's a close relative to one of them.

LightFront is short for Lightweight Front-controller. Unlike most of the CF frameworks out there, it uses only one CFC, and it's just a little bit above 200 lines, so it's straightforward enough most of you reading this with a CF background can look at the core and understand what's going on.

It's conventions based. If you follow conventions, you only have to set three settings in your Application.cfc. That said, there are some conventions that can easily be overridden with another setting. Need to put your views in the /includes/ folder (and subfolders) instead of the default /view/ folder? No problem - that's just an additional setting:

view plain print about
1lfs.viewDirectory = "/includes/";

There are some optional settings, too, but I'll get to that below.

Your controller is all defined in CFCs. You don't need an XML file. As previously stated, all of your settings are defined in your getSettingsForLightFront() function in Application.cfc as a structure. There are no additional XML files to config or define your events... do that in your CFCs.

That's if you use CFC-based controllers. The folder has to exist, but you don't need them to make LightFront work. LightFront has a unique feature. You can also use switch-based controllers, a la Fusebox 2 and 3. It can take a switch file from an old Fusebox app and it will work in LightFront. That's not to say LightFront is 100% Fusebox compatible, and I don't intend on making it that way, but I think we can offer an easier update path on old Fusebox 2/3 sites than even Fusebox/FuseNG can. It does make it a lot easier for a team who wants to move into CFC-based apps to gradually transition into that architecture while at the same time still maintain legacy Fusebox-ian style applications. There are a couple of additional settings to add if you have a Fuseboxian switch/circuit to add to LightFront, similar to how you define circuits in Fusebox, but it's very simple to do.

LightFront is also easy to make work with legacy applications that use no framework at all. Let's say you have an application that has index.cfm, aboutus.cfm, contactus.cfm at the root. No problem. Create a view/home mapping and point it to your root. then, you will be able to call /view/home/aboutus.cfm as displayView("home.aboutus") or displayView("home/aboutus").

That is a double benefit. Let's say you have a site which has a number of static or mostly static pages. You don't need a switch or a CFC controller if you follow simple conventions. If you want to call a static /view/home/aboutus.cfm directly as an event, no problem. As long as all home events are direct calls to view pages and don't use a home.cfc controller or a home switch file, you're fine. Your URL would be ?/do=home.aboutus. LightFront will automatically check for the existence of a home controller. If it doesn't find one, it will try to call /view/home/aboutus.cfm and it will display that as the event. This is also great for prototyping a site, too. You can also define pre-events and post-events, should you need to call events before and after each url called event (they only run once per request).

You can also map assignments from one event class to another (help.contactus goes to home.contactus), change event names (do) and delimiters (.), change naming conventions of the CFCs, and a few other things.

The closest currently supported framework that I know of in ColdFusion to LightFront is FW/1. In fact, Sean beat me to the punch to release FW/1 over LightFront by a few days. I had to go back and see if LightFront was worth it at all to complete, and stopped working on it for a few weeks. After a lot of reflection and some deep analysis of the two frameworks, I decided just before CFUnited that LightFront would continue. FW/1 is very similar, but it doesn't support legacy applications quite as easily as LightFront does, it's more conventions based than LightFront and less flexible in how you code (some would say "more opinionated"), and it ties into ColdSpring or Lightwire and the services layer. I intentionally decided not to do this. It's not that I disagree with using dependency injection/inversion of control or a simple bean factory, or in the idea of a services layer (all my apps have them). It was a conscious decision for LightFront to be a controller framework - nothing more and nothing less. The same can be said for ORMs - LightFront doesn't care whether you use them or not. It's up to you. LightFront only cares about being the controller. In fact, FW/1 and LightFront have so much in common that I could see them merging at some point if that's what people want, or they could travel separate paths. I'm open to either possibility.

Where I see LightFront going depends on what developers that use the framework want. As the first developer to use the framework :-), my thought is if people want what the big frameworks have, those things would go in via a plug-in architecture. Perhaps that would continue to be in the controller folder, or a plugins folder... I don't know. That said, it's fairly simple to build a controller CFC that functions like a filter or add a controller CFC that handles caching, and building those things directly into the framework adds greater complexity to the framework - something I am dead set against. I want to keep LightFront approachable, easy to learn and easy to use.

In fact, one of my goals in making LightFront was to make a simple framework for people to use. I wanted something that didn't require a CS degree or 10 years of CF experience to understand. LightFront should be a framework you can teach any developer the basics in 30 minutes or less you have to learn three functions:

  • callEvent()
  • displayView()
  • relocate()

That, and a few helpful settings changes, are all a developer needs to know.

If you can keep things simple enough for a junior developer to both be productive AND build good code, LightFront will succeed in its main objective.

Anyway, I hope you take a look at the framework, join the Google group and help shape the new framework. And now, back to CFConversations!