An Architect's View

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

An Architect's View

FW/1: The Year Ahead

November 2, 2013 · 15 Comments

With FW/1 Version 2.2 just around the corner - after a long time in incubation - and FW/1 itself being almost four and a half years old, it's a good time to look ahead at what's in store.

When FW/1 was first conceived, it was intended to be drop-dead simple and help on-board developers who were new to MVC and new to frameworks and also new to OOP. It leveraged conventions very heavily to encourage simple controller logic and delegation to a service layer for heavy lifting. That was the conceptual justification for the implicit service calls in the 1.x version and the ability to split controller methods in two - start/end-item - to wrap the automatic call to the service layer.

While that conceptual framework served its purpose admirably, users very quickly grew out of it and needed to start managing service calls more directly. That's why implicit service calls were no longer the default in 2.0 (although you could turn them back on). Even with that change, many users find the queuing of service calls confusing, even tho' controller calls are also queued (although that's mostly invisible to users).

In version 2.5, scheduled for early January 2014, FW/1 will begin the move away from queuing services by deprecating the service() call and requiring a configuration setting to enable its use in your application. In version 3.0, scheduled for release just after cf.Objective() 2014, the service() call will be removed. Along with that, the start/end-item calls will be deprecated in 2.5 and removed in 3.0, since they were only introduced in the first place to create the queued services workflow!

This means that users will need to manage services themselves and of course I recommend using a Dependency Injection framework for that (or at least using some sort of object factory as a bare minimum). Accordingly, DI/1 will have a higher profile in FW/1 2.5 and the two frameworks will be officially bundled together in 3.0. FW/1 will continue to support any bean factory that provides the containsBean() and getBean() API such as ColdSpring (WireBox uses a slightly different API but I plan to provide an adapter for it in 2.5).

Also as part of 3.0, the framework CFC itself will be renamed and the /org/corfield structure removed. The default path will be /framework/one.cfc so your Application.cfc will have extends="framework.one" by default. In 2.5, DI/1 will have adopted this pattern as /framework/ioc.cfc, but since 2.5 will still be backward compatible with 2.2 (after you've added the compatibility setting in Application.cfc), I don't want to force renaming or reorganizing on users until 3.0.

Finally, as part of 3.0, the entire repository will be restructured to better reflect what is considered "best practices" in terms of where you install things and what lives in your webroot (only web-accessible assets!). This will make it easier to get started with the FW/1 skeleton application as a "best practice" out-of-the-box experience.

Note that the DI/1 and AOP/1 repositories will remain active but DI/1 versions will be in lockstep with FW/1 from 3.0 onward, and development will be conducted as part of the FW/1 repository, with releases being merged to the DI/1 repository. Once AOP/1 reaches a similar level of maturity, it will likely follow the same trajectory.

Tags: coldfusion · di1 · fw1

15 responses so far ↓

  • 1 Jon Briccetti // Nov 2, 2013 at 11:25 PM

    Look forward to seeing it in action Sean, thanks for the update
  • 2 Aaron Martone // Nov 3, 2013 at 5:15 AM

    Sean, I'm VERY glad to see you put such high importance on best practices. Though as with many areas of the web, there are no hard and fast rules, these guidelines often prove as excellent starting points for those who are less familiar with the how and why of their implementation.

    I am relatively new to FW/1, MVC and OOP, and am still getting my head wrapped around everything (very daunting, but I'm continuing to learn), however I must say that I enjoy FW/1's simplistic approach to MVC.

    Do not confuse 'simple' with any negative aspect; Simple is good. Da Vinci said that 'Simplicity is the Ultimate Sophistication', and I think FW/1 is keeping that context at heart. Glad to see the ball is still rolling forward.
  • 3 Adam Tuttle // Nov 4, 2013 at 5:14 AM

    So if I understand correctly, service queueing was a byproduct of the desire to simplify the request flow to empower new developers to have good separation of logic and display (via the implicit service calls)?

    You say that it's going away in 3.0 -- does that mean there will be a service() method (or something similar) that runs immediately and returns the result of the service call?
  • 4 Sean Corfield // Nov 4, 2013 at 11:12 AM

    @Aaron, as a Clojure developer I'm extremely aware of the difference between "simple" and "easy" - check out some of Rich Hickey's talks on the subject.

    @Adam, yes, the intention was to focus on a queue of activities that executed in a simple pipeline, to (try to) prevent the mixing of control logic and business (service) logic. In 3.0, users will be expected to call services directly from controllers, which will be injected via DI/1 - which is how most FW/1 users work anyway once they get past the initial "new to MVC" learning curve.
  • 5 Chris H // Nov 5, 2013 at 1:19 AM

    Nice, thanks for the update! Don't know if I'd still be developing with CFML without FW/1 and DI/1. It takes the complexity out of managing an application and lets you focus on the actual application ;)
  • 6 jp // Nov 15, 2013 at 12:53 PM

    Sean, I too appreciate what you've accomplished - Do you have any plans for "getting started" or "understanding" FW/1 (DW/ AOP/) videos? - youTube or Vimeo specifically?

    I find learning much easier with demonstration - when one is trying to submerge themselves into frameworks and oop simply 'reading' can get daunting as terms and concepts seem to run into one another.

    Thx again
  • 7 Sean Corfield // Nov 18, 2013 at 11:12 PM

    @jp, I don't have the knowledge / skills to produce videos or screencasts - I'd love to see some folks in the community produce them tho'!
  • 8 Bill Davidson // Dec 1, 2013 at 7:23 PM

    So glad to see these changes, Sean. We've moved away from the built in services functionality awhile ago, and this is such a good move for the framework.

    Also integrating DI/1 will be very welcome. Any chance we will get a release version soon or will it stay in 0.x beta for the foreseen future?

    Thanks for continuing to support the FW with development. I'd love to help. Perhaps, I could take on the video aspect since before "falling back" into development that's what I did for over a decade.
  • 9 Sean Corfield // Dec 2, 2013 at 8:54 AM

    @Bill, DI/1 is at 0.5.0 now and has no open issues so I expect to mark it as 1.0.0 in sync for the FW/1 2.5 release.

    I plan to fix the remaining outstanding two issues on FW/1 2.2 RC1 today and issue RC2. RC1 has been out for a month and only two minor issues have been reported. I expect to go from RC2 to gold pretty quickly.
  • 10 Sean Corfield // Dec 2, 2013 at 8:55 AM

    @Bill, the community would certainly value any video tutorials you find time to create!
  • 11 sinast // Dec 9, 2013 at 4:09 AM

    would you say you're moving away from the original intention of a very simple to use framework and toward a more complex one (like others out there) that newbies will be overwhelmed by? unless a pro developer, figuring out what "dependency injection" means is enough to scare most away.
  • 12 Sean Corfield // Dec 10, 2013 at 10:22 PM

    @sinast, the framework will remain simple - the key will be writing the getting started guide in the right way to show how easy it is to add a Model - services, beans, etc - without actually needing to worry about "dependency injection".
  • 13 Nathan D // Dec 18, 2013 at 4:05 PM

    A humble suggestion -- for those who tend to bundle the framework.cfc into the root of our apps (especially when we deliver self-contained apps where we will have little or no power over the configuration of the server) the name "one.cfc" might be suboptimal. In the tradition of "org.corfield" perhaps you'd consider "one.framework" instead of "framework.one"?
  • 14 Sean Corfield // Dec 18, 2013 at 6:38 PM

    @Nathan, you can rename the CFC if you want to do that (you already can).
  • 15 Nathan D // Dec 18, 2013 at 11:29 PM

    Yes, of course ;)

    Was making a pitch for the default to be a little more descriptive in naming the file itself ("framework.cfc" vs. "one.cfc") and in being a bit more friendly to those not using the assumed folder structure.

Leave a Comment

Leave this field empty