As many people may know, the creator of FW/1 Sean Corfield has moved on from doing cfml development for some time now. Despite this he has continued to maintain the framework up until this point, however it has come time for someone else to step up if the project is to continue to move forward.

Now I've been out of the loop for the past few years for personal reasons and have had little time to devote to side projects, but with the last few months I've found my personal time free'd up and a renewed energy for coding outside of work. This coupled with my love of FW/1 and maybe a hint of masochism has prompted me to step into the role of project maintainer.

The Future

So what does the future hold for FW/1? Well as it stands the framework is mature and stable, which is a very good thing and something to be maintained for any future releases. With that in mind there are not going to be any significant updates in the near future. While there are a few issues in the queue to investigate, the are no new features in the plan for next the 4.x branch.

Instead, my plan for now is to get back up to speed with the codebase and look at updating/expanding on the existing documentation. Now how I'm going to achieve that is still up for debate. On one hand the jekyl pages are nicely formatted, but the wiki is quick and easy to maintain and is more condusive to group maintenance. Eventually a decision will be made but again, slow and deliberate is the way forward.

5.0?

Now, Sean and I have discussed some ideas for the 5.0 version of FW/1 in the past. The rough idea was a re-architecting of the underlying lifecycle logic to fill in some holes in subsystems. The goal was to prepare for adding two significant changes later on.

1. A subsystem specific master controller which would allow for a subsystem to have subsystem wide before() and after() methods. This would change the controller lifecycle for subsystems from:
   
   
   • "application"-before() -> "section"-before() -> "section"-item() -> "section"-after() -> "application"-after()
   • to
     
   • "application"-before() -> "subsystem"-before() -> "section"-before() -> "section"-item() -> "section"-after() -> "subsystem"-after() -> "application"-after()
2. Add a setup() or configure() method to the subsystem controller which would allow for initialization for that subsystem to exist inside that subsystem instead of inside the setupsubsystem() method in application.cfc. This is vitally important for making subsystems more modular.

While these are changes that I have ad-hoc implemented in my own modular fw/1 code and I can attest the their usefulness, a rewrite of the underlying code for 5.0 would potentially introduce breaking changes and require a significant amount of time. It is my hope to get to that point eventually but for now I don't feel it a good use of resources.

Also the community may decide that there are other features/changes that would add more value. In which case I would welcome any and all suggestions either here or on the github issue tracker.