Update to 'Core' Framework. Now in GitHub!

A while ago I shared a small framework I created which I use to develop pretty much all of my projects (both open source and paid engagements). The framework, as is usual for web frameworks, follows the MVC and Front Controller patterns; also like Sean Corfield's FW/1 and Barney's FB3 Lite (and many others) it has an emphasis on minimalism and makes an effort to stay out of the way as much as possible. I recently made some changes to the framework and wanted to share them with the community.

As far as version numbers go this is version 1.4. The main change from the previous version is that now the entire framework code (all 5 files) is contained on a single directory named 'core' instead of being mingled with the application files. Also there is more control over how to structure the application files and folders. Pretty much all the changes are inside the framework code and how it is configured, so all the semantics and workflows remain the same.

How 'Core' Works

Core is your typical front-cotroller, single point of entry, event-based framework. This means that all requests are directed through a single index.cfm, with a URL or Form parameter used to indicate a method on a CFC to execute (the "event"). These methods or "event handlers" are the ones that contain the logic of what to do and what to display. Typically here is where you call your service objects, do databases queries, or whatever else you need. Core really doesn't care of what you do inside the event handler, go OO-nuts, or go procedural. Thats up to you. Core adapts to simple apps of a couple of pages and also to larger multi-tiered apps.

Event handlers also indicate what 'views' and 'layouts' to display.

Structure of a 'Core' Application

The codebase for Core consists of only a few files (2 cfcs, 3 cfm, and a couple of images) which can be placed either on a central location or as a subdirectory of your app. You can choose whetever is most appropriate to your situation.

Application.cfc

The simplest way to create a Core application is to have your Application.cfc extend core/coreApp.cfc and then programmatically set all the configuration settings. However if having your Application.cfc extend another component is a problem, then you can also just create an instance of coreApp and then call the onRequestStart() method on every request (or at least on every request that you want to be handled by Core)

For example, this is how a minimal configuration may look like:

Application.cfc:

Folder Structure

Core doesn't require you to have any particular directory structure, so if you want you can throw all your application files on a single directory (good for small apps), or you can be a bit more structured and separate your application files into folders. Using the configuration settings you can tell Core where to find the event handler CFCs, the views and the layouts; and these locations can be either within your app directory (the default) or anywhere else (to share between apps).

This example shows how to setup a Core app with a standard folder structure, with all folders relative to the application's root folder.

Application.cfc:

Or this one, for an application that uses views and layouts shared by other applications:

Application.cfc:

Event Handlers

Event handlers in Core are methods in components that are where all processing is done. Events are called via an 'event' parameter that can be passed either via URL or Form. The value of this parameter indicates which component and which method to execute.

This example shows a simple event handler (the main.home from the previous examples)

main.cfc:

Modules

This is a way for providing a bit of modularity to Core applications. You can use modules to group sets of views and handlers together, thus providing more options for structuring the application code. This is useful specially for large codebases when you may not want all your handlers or views bundled together in one single directory. Also this can be used for having sections of applications that can be "plugged" into larger applications.

Settings & Services

I think this is a feature that sets Core apart from other light frameworks. Although Core doesn't require the use of XML files to configure the framework, it does provide the support for using an XML file to provide constants or settings to be used exclusively by your application. For example you can use this feature to provide values for things such as an administrator's email address for debugging emails, or the URLs for Webservice WSDLs, etc. Anything that you may not want to hardcode on your application but want to keep on a central place and relatively easy to modify when needed.

Also you can use this XML file to declare 'Services'. These are instances of components that are available application wide. If this sounds familiar then yes, it is just a very small Singleton factory, however it is not intended as a replacement of a full blown DI factory (like ColdSpring) This is only a convenience for when you need a quick and easy way to instantiate services, or even use it to instantiate your real DI Factory instance.

Available from GitHub

I placed the code files along with a really small sample app and more usage details at github so feel free to download, fork or clone as you wish. You can find the code at:

http://github.com/oarevalo/core

UPDATE: I uploaded a port of the LitePost sample app to github to show how Core is used in a real application. You can find it here