So now that we are here, what is in store for FW/1. Well there are some new outstanding PR’s that will be getting reviewed for 4.3.1 and then most likely some updates to how the documentation is generated since jekyl has proven to be so much of a pain to work with.
After that the plan for now is to continue basic maintenance. The question I find myself asking is, is further enhancing the framework a good idea? At this point it has grown significantly from the original ethos of a small simple single file framework that Sean started with and additional complexity is not always a good thing. I do have some ideas of further enhancing the subsystem behaviors but I’ve run into issues that make me think a ground up rewrite of certain sections of code may be necessary. Additionally I know Sean was looking into the possibility of a plugin system, but is there a desire for something like this?</p>
These are all questions I will be pondering over the next few months while we work on getting the beta to stable status.
]]>After seeing this blog post, Steven Neiland stepped up to take over maintenance of the framework! He has been a long-time user of FW/1 and designed the “2.0” version of subsystems four years ago. I’m looking forward to working with Steven to ensure a smooth hand-off over the next few months. Thank you!
It’s been a year now since FW/1 4.2.0 was released so I wanted to revisit the roadmap document from that time. At the end of December 2018, I posted to the FW/1 channel on the CFML Slack (and to the FW/1 mailing list) that my involvement with CFML and FW/1 was coming to an end. I’ve asked, several times over the years, for new maintainers to step up for FW/1. Nolan Erck has permissions on the GitHub organization (as owner) but I’m not expecting him to lead development as he has a lot of other things on his plate. At this point, FW/1 is extremely stable and (fairly) well-documented. 4.0.0 was released in Fall 2016. There have been (minor) maintenance releases each year since (4.1.0 in July ‘17 and 4.2.0 at the end of March ‘18).
There have been two very small enhancements on the develop branch since then (thank you Carl Von Stetten and Matthew Clemente) but not enough to warrant a new release (and, with CommandBox, it’s easy enough to install that branch anyway: box install fw1@be
). At this point, unless one or more genuinely proactive and engaged maintainers come forward, 4.2.0 will probably be the last official release of the framework.
The roadmap document (linked above) talks about a refactoring of the lifecycle functionality that was intended to simplify Application.cfc
and the “Alternative Application Structure” in current FW/1 apps but it would ultimately have been a significant breaking change (hence the mention of an intermediate 4.5 migration release before the breaking 5.0 release). Since that was mostly driven by my architectural preferences, I don’t see any value in any new maintainers following that path – I never fleshed out, on paper, what that should look like so I’m going to close out the associated GitHub issue for it. Making subsystems more self-contained and more “pluggable” probably should be a goal for any new maintainers, but tackled more incrementally. Beyond that, I don’t know what should be on a roadmap now: perhaps minimal, careful maintenance to fix bugs and stay compatible with new versions of Lucee and Adobe ColdFusion is all that is really needed?
I’ve made no secret of how my work has transitioned from CFML to Clojure over the last roughly nine years. I initially ported FW/1 to Clojure but then decided to sunset that port, as it became clear that FW/1 added very little value to a (simpler) combination of the Ring, Compojure, Component, and Selmer libraries. At work, we ported our CFML FW/1 apps to Clojure FW/1 apps and then to plain Clojure apps a few years ago. Our primary CFML app – built with ColdBox – was retired completely this month, in favor of a React.js-based front end and a Clojure-based back end. We have two ColdBox apps remaining: a small, customer-facing app that we plan to redesign and rebuild (in Clojure) over the next year, and a medium-sized internal “administration” app that we started migrating to Clojure last year. We’ve gone from four servers running Lucee to just one, and expect to retire that before year end.
I got started with CFML over seventeen years ago, when my then-employer Macromedia acquired Allaire, and as a technology it has been good to me throughout that time – at Macromedia, at Adobe, as a freelancer, at Broadchoice (Flex, Groovy, and Railo), as part of Railo Inc, as a freelancer again, and for several years at World Singles Networks where I also found myself writing Scala for a year or so and then Clojure. The CFML community is one of the friendliest, most supportive technology groups I’ve met, in a career that spans back to the early 80’s, and I’ve missed seeing my CFML friends at conferences as my work focus has shifted – it’s been six years now since I last attended a CFML conference!
I expect I’ll still lurk on the CFML Slack for quite a while, and I’ll stay subscribed to the FW/1 mailing list – forever, I expect – so folks can still reach me for FW/1 and CFML questions and general chit-chat.
]]>This is a maintenance release for FW/1 4.1.0 that includes a handful of bug fixes and some experimental work to try to support ColdBox modules.
]]>This is a maintenance release for FW/1 4.0.0 that includes a number of bug fixes and some minor enhancements. See this blog post about the release candidate for the main changes in this release. Since the release candidate, most of the work has been on updating the documentation and adding an example of using a custom template engine (Mustache) with FW/1.
Note that 4.1.0 includes an important bug fix for 4.0.0 which addresses a race condition that could cause transient beans to be partially resolved, leading to dependencies not being available under heavy load conditions.
Lucee 5.x is now an officially supported platform for FW/1, along with Adobe ColdFusion 10, 11, and 2016, and Lucee 4.5.
]]>This is a maintenance release for FW/1 4.0.0 that includes a number of bug fixes and some minor enhancements. The most important bug fix addresses a race condition that could cause transient beans to be partially resolved, leading to dependencies not being available under heavy load conditions. My thanks to John Whish and John Berquist for their work in tracking that down and providing a patch to address it!
Other bug fixes mostly focus on error handling.
The enhancements include making session handling pluggable, improving handling of missing views, and a new onReload()
extension point. In addition, the process to test FW/1 has been overhauled: it now uses CommandBox and TestBox, making it much easier for contributors to run tests locally, as well as expanding the matrix of servers/versions that can be automatically tested.
Finally, Lucee 5.x is officially supported by this release. Although earlier versions of FW/1 “worked” on Lucee 5.x, the Clojure integration (introduced in FW/1 3.5) only worked in limited cases on Lucee 5.x so I could not consider it “officially supported” (for example, at World Singles, we could not upgrade to Lucee 5.x because it breaks our use of Clojure from CFML). In order to support Lucee 5.x officially, the Clojure integration functionality has been removed from FW/1. The files that provide Clojure integration are still available in the cfmljure repository on GitHub.
I consider this Release Candidate to be “production-ready” so I would appreciate as many users upgrading and testing it as possible!
Thank you to everyone who contributes to FW/1 in every way!
]]>renderData()
result elements.OPTIONS
verb.Dependency Injection (DI/1) has also received a lot of attention in this release, including the addition of a flexible and powerful builder syntax for declaring beans.
See the FW/1 4.0.0 Change Log for full details of all the enhancements and bug fixes. Please note that there are a few breaking (or potentially breaking) changes since 3.5.1, with the most notable one being that Adobe ColdFusion 10 is now the minimum supported version. Support for Railo and Lucee has not changed.
This will be followed by a 4.1 maintenance release and a 4.5 migration release, which will pave the way for some breaking changes planned for the 5.0 release. For more details of future plans, consult the FW/1 Roadmap.
]]>For full details, read the Change Log for FW/1 4.0.
]]>enableJSONPOST
setting has been renamed to decodeRequestBody
.
This is a breaking change if you were using that setting in the earlier Alpha / Beta builds:
you will now get an exception and will need to update your application’s configuration.
For full details, read the Change Log for FW/1 4.0.
]]>For full details, read the Change Log for FW/1 4.0.
]]>The focus of the 4.0 release is on improving REST support. Improvements include:
renderData()
result elements.OPTIONS
verb.In addition, DI/1 has had a number of enhancements, including the addition of a builder syntax for programmatically declaring beans.
For more detail, read the Change Log for FW/1 4.0.
]]>FW/1 3.5 has been out for a few months now and I want to talk about what’s coming this year. FW/1 4.0 is well under way and the themes are REST APIs and enhancements to DI/1. You can read the FW/1 4.0 change log here to see how much has been done so far. There are only a few issues left for 4.0 so we’re close to the first Alpha release at this point.
Why the 4.0 version? A major version number change indicates breaking changes. 4.0 drops support for Adobe ColdFusion 9.0.x because it relies on closures. Frankly, I’d like to drop support for Adobe ColdFusion 10 so I could rely on using member functions, but I feel it’s important to support two major versions. Just bear in mind that Raijin – ColdFusion 2016 – is coming and when that’s released, I will drop support for ACF10!
Aside from the minimum version support, FW/1 4.0 includes a (potentially) breaking change around property
declarations: if a property
includes a type or default, it will no longer be considered for injection. In FW/1 3.5, typed properties could be excluded if you specified omitTypedProperties : true
. That is the default in 4.0 so you can still restore the earlier behavior. In addition, 4.0 now ignores defaulted properties but you can specify omitDefaultedProperties : false
to override that new behavior.
The next planned version of FW/1 will be 4.5 – a fairly major release that will pave the way for 5.0, in the same way 2.5 paved the way for 3.0. In 5.0, the request lifecycle methods will move from Application.cfc
(or your custom CFC that extends framework.one
in the Alternative Application Structure) to a separate CFC, and subsystems will also be able to specify a request lifecycle with a subsystem.cfc
– and subsystems with such a CFC will be eagerly loaded at application startup (whereas subsystems are lazily loaded today). In order to provide a smooth upgrade path, FW/1 4.5 will support most of those features but disabled by default and will provide warnings or throw exceptions if the behavior would change in 5.0.
As always, I want FW/1 to be driven by your needs so please raise issues on the mailing list or on GitHub so that your voices are heard and can drive future versions of one of CFML’s most popular MVC/DI/AOP frameworks!
]]>The major new features in FW/1 3.5.0 are:
Application.cfc
extends the FW/1 component. Read about the Alternative Application Structure. Some of the examples have been updated to use this approach so you can see how it works in practice.box.json
file and is hosted on ForgeBox so it can be easily installed via CommandBox.In addition to the major features, the following enhancements have been added:
redirect()
allows queryString
to be a struct, like buildURL()
.isFrameworkReloadRequest()
is now public in case an application needs to take action when the framework is reloaded.getSubsystemSectionAndItem()
added to supplement getFullyQualifiedAction()
(the latter omits the subsystem if it is empty).And the following bugs have been fixed:
renderData()
could kill sessions (this was backported to 3.1.1).expandPath()
returning the wrong directory on ACF11 when the path has a trailing /
.Finally, FW/1 includes experimental support for Lucee Language, so if you are running a prerelease build of Lucee Server that has Lucee Language support enabled, you can write controllers and views etc in .lc
or .lucee
files and FW/1 will use them.
You can read the full list of changes since 3.1 on GitHub, along with accepted pull requests since 3.1.
]]>This Release Candidate contains a few bug fixes discovered since Release Candidate 1. I consider this stable enough to evaluate for production usage at this point – I expect this RC to be the Gold Release unless end user testing uncovers a showstopping issue in the next week or two!
You can read the full list of changes since 3.1 on GitHub, along with accepted pull requests since 3.1..
]]>This Release Candidate contains just bug fixes since Beta 2. Beta 2 contained mostly bug fixes since Beta 1, with one small enhancement to DI/1 (liberal
plural support, e.g., libraries
becomes library
).
You can read the full list of changes since 3.1 on GitHub.
]]>The focus of this release is integration:
.cfc
), Clojure (.clj
), or Lucee (.lucee
).cfm
) or Lucee (.lucee
)Application.cfc
to use FW/1 without extending framework.one
You can read the full list of changes since 3.0 on GitHub.
The documentation for 3.5 has been completely overhauled with complete descriptions of all the new features, as well as many clarifications and expansions of existing features. In particular, you’ll want to check out:
]]>Go get it installed, then read on!
Now you have box
installed, here’s how to get up and running with FW/1 easily:
> box
CommandBox:mydir> install fw1-commands
... you only need to do this once ...
CommandBox:mydir> mkdir example
CommandBox:mydir> cd example
CommandBox:example> fw1 create app example basic
CommandBox:example> install fw1
... installs stable 3.1.2 version ...
CommandBox:example> start
At this point it’ll open a browser running your new skeleton FW/1 app. Happy coding!
Note that you don’t need to have installed a CFML server, or set up a webroot - box
can start a CFML server in any directory so you can get up and running quickly!
You can check out the various FW/1 commands available inside box
but, like Ruby on Rails, they let you quickly add new controllers, views, subsystems and so on to your application. Huge kudos to Tony Junkes for contributing this to the FW/1 family of projects!
Going forward, my plan is that install fw1
will always install the current stable (master) version — I just need to remember to keep it up to date! — and you can also install specific versions (currently fw1-3.1.2
and fw1-3.5.0
). The latter installs from the develop branch. Support for true multiple version installs is planned for box
, possibly next month.
One of the things that is really nice about this is you can switch FW/1 versions as easily as:
CommandBox:example> uninstall fw1
CommandBox:example> install fw1-3.5.0
Now your app is running 3.5.0 (Alpha 2) instead of the stable release!
]]>As indicated in July, work on FW/1 3.5 had been progressing in parallel (the first time two releases of FW/1 have been worked on concurrently!) and you can already download FW/1 3.5 Alpha 2. Yes, there was an Alpha 1 as well, but as work progressed on the massively overhauled 3.5 documentation, some important usability enhancements appeared and a new alpha was released within 24 hours! In particular, the Clojure and CFML Sitting in a Tree section has been extensively updated and includes a fully worked example of how to create FW/1 application from scratch using the REPL to create Clojure services and controllers, with CFML views and layouts!
You’ll also probably notice that the FW/1 website has had a facelift, finally getting the look’n’feel that Kevin Stannard designed five years ago. Better late than never, and huge thanks to Kevin again for his wonderful logo design and choice of colors! The 3.5 documentation now includes a table of contents on each page, making it easier to navigate (this will probably get backported to 3.1 and 3.0 at some point).
In addition to the ongoing work on FW/1 3.5, we also have an important bug fix release for the 3.1.x version which addresses a potential problem with REST APIs.
Finally, if you’re a CommandBox fan, we have good news: you can now easily install FW/1 3.1.2 and 3.5.0 (prerelease) via box
. I’ll be blogging about this shortly. The 3.1.2 release is exactly the same as 3.1.1 (including the version number!)
but it includes box.json
for compatibility with ForgeBox / CommandBox. In addition, Tony Junkes has contributed an initial set of box
commands for FW/1 that let you get up and running quickly. This will be covered in the next blog post.
FW 3.1 is a maintenance release of the 3.x series, containing a number of bug fixes and enhancements. The main new feature of release 3.1 is the addition of AOP/1, thanks to the tireless work of Daniel Budde.
AOP/1 brings Aspect-Oriented Programming to FW/1 applications by extending the capabilities of DI/1 with “interceptors” that can be automatically woven into your beans to allow you to call additional methods before, after, or instead of (“around”) the native methods on your beans. Please read the all new AOP/1 documentation provided by Daniel Budde for more details on how to use this powerful new feature.
renderData()
now supports both html
, rawjson
and jsonp
data types.redirect()
now supports a header
argument to allow for custom redirect-like behavior such as might be needed in a Single-Page-Application or heavy ajax usage.^
to anchor the match to the start of the request string.routesCaseSensitive
option.diEngine
, diComponent
, diLocations
, and diConfig
.diConfig
._
and -
characters only. This is potentially a breaking change if you have used unusual characters in placeholder variable names that are legal in CFML identifiers!isConstant()
method could fail for manually created and managed beans.Application.cfc
was not always correctly autowired as a Controller.renderData()
, that content could corrupt the result. A content reset is now performed in such cases.As part of my commitment to diversity in IT, Framework One now has a Code of Conduct that encompasses all aspects of interaction with the project: on GitHub, on the mailing list, and in presentations given by community members to promote the framework. This brings Framework in line with a number of progressive open source projects that have adopted a Code of Conduct as a way to make the open source software community more welcoming and more inclusive.
The star contributor for this release is Daniel Budde for rewriting AOP/1 (twice!) so it is ready for inclusion with FW/1! Thank you!
Other contributors, in alphabetical order of GitHub name:
And, yeah, I did a bit too, but FW/1 wouldn’t be where it is today without contributions from the open source CFML community - thank you everyone!
For a complete list of changes since 3.0:
Release 3.5 Alpha 1 will follow shortly, with a focus on language integration, bringing automatic support for Clojure code in the Model and Controllers, as well as first class support for the Lucee Language in the Model, the Views, and the Controllers.
]]>These are the changes since RC 1:
For a complete list of changes since 3.0:
At this point, release 3.1 should be considered “production ready” and only critical bug fixes will be included between now and the “gold” release. It will be merged to master tomorrow in preparation for the final release at the weekend.
As noted before, release 3.5 will follow fairly quickly after that, with a focus on language integration, bringing automatic support for Clojure code in the Model and Controllers, as well as first class support for the Lucee Language in the Model, the Views, and the Controllers.
]]>