Brian Meloche's Blog I'll blog about ColdFusion, weight loss, podcasting and life with too many pets! :-)

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 on RIAForge
• Sample Application for LightFront - You can also download the sample application here (no skeleton yet, just a sample).
• LightFront's SVN repository
• LightFront Google Group

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:

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!