An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Introducing FW/1

July 20, 2009 · 4 Comments

Over the last few days I've been working on a new MVC application framework for ColdFusion. It's very lightweight and completely convention-based. Beyond this introduction, I won't be blogging about it here but you can read all about about on the project blog over at Framework One's RIAForge website. That's where you'll also find the forums, wiki, source code repository and bug tracker. The blog also has a link to the new mailing list if you'd rather use that instead of the forums. What is FW/1? Read the RIAForge project description and introductory blog post there. Why create FW/1? Again, read the project blog on RIAForge!
View count: 1156

Tags: architecture · coldfusion · fw1

4 responses so far ↓

  • 1 Ron Hopper // Jul 20, 2009 at 2:04 PM

    Sean, this is great. It's high time for such a straightforward (yet powerful) MVC framework. Kudos!

  • 2 Josh Nathanson // Jul 21, 2009 at 12:26 PM

    Good stuff Sean. Interestingly I came to adopt many of the same conventions in my own personal development. Only difference is I tend to organize the file structure per object, like so:
    person/controller.cfc
    person/service.cfc
    group/controller.cfc
    etc.

    I also use the convention ?action=component.method and pass a struct containing form/url data.

    Great job, this is really needed in the CF community.

  • 3 Sean Corfield // Jul 21, 2009 at 3:46 PM

    @Josh, my only concern about using a structure of object/controller.cfc and object/service.cfc is that it might lead toward the "5:1 Syndrome" path where you have a bean / dao / gateway / manager / controller for every object in your application.

    In my applications, I generally have one controller per "area" of the application and one manager per "area" of model functionality (and then a combined dao/gateway for related objects). That way controllers are bound to the UI but services/managers are bound to the model and act as facades to business logic, independent of specific objects.

    Now, in FW/1, I've allowed for the shortcut of services that are essentially bound to the UI as well as controllers but that's an acknowledgement of the fairly common practice of thin controllers, delegating to services that shadow those controllers - and it can be a reasonable trade off for simplicity (especially in smaller applications that only have one controller / one service). I'm not entirely happy with this compromise but it is a pragmatic choice to allow automatic service invocation when little (or nothing) needs to be done in the controller.

  • 4 Jaime Metcher // Jul 21, 2009 at 4:27 PM

    Nice. We came to similar conclusions after seeing projects using some frameworks simply produce spaghetti XML instead of spaghetti ColdFusion. Writing controllers just isn't a hard problem, so it's nice to see the appropriate "weight" of framework applied to it.

Leave a Comment

Leave this field empty: