An Architect's View

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

An Architect's View

FW/1 2.5 Release Candidate 0

January 11, 2014 · 2 Comments

You can download it from the FW/1 Releases page on Github.

I want to get this out there for folks to experiment with since it contains a fundamental change (regarding services).

FW/1 2.5 is a "release candidate" insofar as it is feature complete, but it is not yet documented, and the changes to the examples are not yet complete.

#151 Tracing changes:

  • frameworkTrace() is now a public method and takes a message and an optional value that will be added to the trace output.
  • disableFrameworkTrace() and enableFrameworkTrace() do what they say on a per-request basis.
  • setupTraceRender() is called at the start of the rendering process so you can intercept rendering.
  • getFrameworkTrace() returns the raw trace data array at the point where it is called: if you want to manage trace rendering or recording yourself, call this method in setupTraceRender() and then call disableFrameworkTrace() to suppress the default rendering.

#207 Service Queue Deprecation - the big one!

  • new setting suppressServiceQueue which defaults to true: when this is true, you can no longer call service() and attempts to use startItem()/endItem() will also fail - see below; if this setting is changed to false, the behavior of FW/1 2.2 is restored, but you will see deprecated messages appearing in the console every time service(), startItem(), or endItem() is called.

#208 WireBoxAdapter:

  • you can now use WireBox as the bean factory with FW/1 and it will autowire services, by name, into controllers: see the new examples/wirebox app for an example of how to do this.

#213 populate() now accepts properties:

  • previously populate() could only inject elements of the request context into a bean; now you can specify a new properties struct argument that will be used instead of the RC struct.

#216 buildCustomURL():

  • this makes it easier to build route-based URLs instead of regular action-based URLs: buildCustomURL( "/product/123" ) will construct a URL with the same sort of prefix that buildURL() would create, followed by the URI argument.

#221 recognition of XSS in default error page:

  • the code now does a minimal bit of URL encoding but admonishes developers to either do better encoding (which may be CFML engine specific!) or simply provide a real error page!

#229 isCurrentAction():

  • let's you test if a given action is equal to the currently executing action - as you might need in navigation elements to highlight the currently active tab.

The UserManager example has been overhauled to use DI/1 and no longer rely on the service queue. All the other examples will be overhauled before I release 2.5. The documentation will also get updates (of course) and the Getting Started page will probably be rewritten from scratch to lead new users down the right path as they encounter services (i.e., using a bean factory).

So what's the deal with the service queue? This was something introduced back in 2009 and was intended to provide a simple-to-use convention-based way to ensure the appropriate service methods are called with the appropriate arguments automatically. This was supposed to encourage FW/1 users to keep controllers simple and to put their business logic in service CFCs, since it was so easy to do that. For anything more complex, you could queue up additional service calls and they'd be called automatically between the start and end controller methods for a given action, or after the primary controller method. In other words, it was intended to make it easy for you to "do the right thing". In reality, users quickly outgrew the convention and started to manage services directly. It's arguable whether it really worked well even for the simple cases. FW/1 2.5 is the first step to moving users in that direction!

Feedback and suggestions welcome, as always!

Tags: coldbox · coldfusion · fw1

2 responses so far ↓

  • 1 Ryan Guill // Jan 12, 2014 at 7:51 AM

    Thanks for the work Sean. We are still young on fw/1 but I am already liking it better than coldbox for my uses.

    Re: the wirebox adapter, are there feature differences between di/1 and wirebox that make folks prefer one over the other? or is it just api differences mostly?
  • 2 Sean Corfield // Jan 15, 2014 at 9:14 PM

    There are huge differences between DI/1, ColdSpring, and WireBox - philosophical differences that have driven the development of each DI / IoC framework.

    Happy to discuss on the FW/1 mailing list if you really want to dig into it...

Leave a Comment

Leave this field empty