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:

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:

http://kb2.adobe.com/cps/529/cpsid_52915.html

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!

New Podcast I am listening to... cfframeworks.com

I found a new podcast this week...

Nick Tong of CFFrameworks.com - http://cfframeworks.com/blog/ started a ColdFusion Frameworks podcast in January, but I just found it earlier this week. I have been catching up with the podcast, and it's a wonderful interview-type of podcast. I highly suggest checking it out if you are a ColdFusion developer!

Here at the Frameworks Conference!

I am in Bethesda, MD, tonight... waiting for tomorrow's start to the Frameworks Conference. Did I ever blog I was coming??? Hmm... maybe not... but I did mention it on a list or two.

This is my third Frameworks, although the first two were back when the only Framework featured was Fusebox (2001 and 2002). I'm looking forward to what is sure to be an eventful couple of days.

The flight and subway ride here were uneventful, but I almost didn't make my flight... thanks to the airport security check, which took 45 minutes. I had to run... imagine a 350+ pound man running at full tilt through the airport!!! And, to boot, my gate was literally the farthest gate to get to... but I made it. Barely... but I made it. This hotel is very nice. The rooms are nice. I registered already. Things start at 8... so I'll be getting to bed in a minute.

Some of the presentations on Thursday I am going to try to make include:

  • Matt Woodward's Building Sustainable Software with Frameworks
  • Chip Temm's Model Driven Development and Code Generation
  • Steve Nelson's CFCs ARE the Framework (I'm tempted to see Peter Farrell here, but I have already seen this preso twice, once for my CFUG)
  • John Paul Ashenfelter's Testing Frameworks (may see Peter Bell's Application Generation - Beyond Scaffolding)
  • Rob Gonda's Intro to Object Factories (although the Model-Glue/Ajax also sounds interesting)

Mach-ii 1.1.1 has FINALLY been released as a stable version

I was happy to get an email from the Mach-II Google Group that Mach-ii version 1.1.1 has been released as a STABLE version, no longer considered beta.

http://mach-ii.com/code.cfm

I'm not sure when we'll upgrade at the office. Since it's been a long while between 1.1.0 and 1.1.1, I suspect we'll upgrade sooner, rather than later. I'd welcome getting comments from people that have upgraded and tell me whether it's been easy or if there have been any gotchas.

Kudos to Peter and Matt for giving birth to their new baby! :-)

The BIG Mach-ii project is LIVE!!!

It's been a trying six months or so, but I am happy to report that the big Mach-ii project I have been working on at the office officially went live this morning. Hopefully, the 60+ hour weeks, 75 at the peak, will start to be reduced over the next few weeks.

Unfortunately, I cannot tell you a lot about the project. What I can say is that it's a B2B website that is designed to replace our existing site, and also has drop shipper functionality, so that we can sell products for other companies. It also completely ties into our mainframe systems for order processing and fulfillment. It's written entirely in Mach-ii, rewritten from the ground up, and is almost entirely OO (one legacy sub application was not entirely converted, but the rest of them were).

It's been a learning experience, that was not always smooth. In fact, there were times when it was quite bumpy. However, it has taught us a lot and the lessons learned are helping us redesign and streamline our development process.

There will be a lot more going on with this project. We have to make a few changes in version 2, and begin to port over other aspects of the business to the new site, but version 1.0 is out the door!