framework-one.github.io/atom.xml at source · framework-one/framework-one.github.io

547 lines (390 loc) · 56 KB
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title><![CDATA[FW/1 - The Invisible Framework]]></title>
  <link href="http://framework-one.github.io/atom.xml" rel="self"/>
  <link href="http://framework-one.github.io/"/>
  <updated>2015-07-07T16:43:21-07:00</updated>
  <id>http://framework-one.github.io/</id>
    <name><![CDATA[Sean Corfield]]></name>
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>
    <title type="html"><![CDATA[FW/1 3.1 Release Candidate 2 Available!]]></title>
    <link href="http://framework-one.github.io/blog/2015/07/07/fw1-3-1-rc-2/"/>
    <updated>2015-07-07T16:40:00-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/07/07/fw1-3-1-rc-2</id>
    <content type="html"><![CDATA[<p>The second Release Candidate of FW/1 3.1 is now available for testing. You <a href="https://github.com/framework-one/fw1/releases/tag/v3.1-rc2">download FW/1 3.1 RC 2 from GitHub</a>.</p>
<p>These are the changes since RC 1:</p>
<li>Major overhaul of AOP/1; intercept by CFC type; intercept by CFC name regex (Daniel Budde).</li>
<li>Routes now support regex restriction on placeholder variables (Guillaume Boivin).</li>
<p>For a complete list of changes since 3.0:</p>
<li><a href="https://github.com/framework-one/fw1/issues?q=is%3Aissue+is%3Aclosed+milestone%3A3.1">Issues Closed</a></li>
<li><a href="https://github.com/framework-one/fw1/pulls?q=is%3Apr+is%3Aclosed+milestone%3A3.1">Pull Requests Merged</a></li>
<p>At this point, release 3.1 should be considered &ldquo;production ready&rdquo; and only critical bug fixes will be included between now and the &ldquo;gold&rdquo; release. It is the default download on RIAForge and will be merged to master tomorrow in preparation for the final release at the weekend.</p>
<p>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.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.1 Release Candidate 1 Available!]]></title>
    <link href="http://framework-one.github.io/blog/2015/06/28/fw1-3-1-rc-1/"/>
    <updated>2015-06-28T17:00:00-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/06/28/fw1-3-1-rc-1</id>
    <content type="html"><![CDATA[<p>The first Release Candidate of FW/1 3.1 is now available for testing. You <a href="https://github.com/framework-one/fw1/releases/tag/v3.1-rc1">download FW/1 3.1 RC 1 from GitHub</a>.</p>
<p>These are the changes since Beta 2:</p>
<li><code>renderData()</code> supports <code>"jsonp"</code> (Giancarlo Gomez) and <code>"html"</code>.</li>
<li><code>renderData()</code> now causes a content reset before rendering the data (Giancarlo Gomez).</li>
<li>Subsystem-specific configuration can now override <code>diEngine</code>, <code>diLocations</code>, and <code>diComponent</code>. Previously it could only override <code>diConfig</code>.</li>
<li><code>setupApplication()</code> no longer runs twice when first request is also a reload request.</li>
<p>For a complete list of changes since 3.0:</p>
<li><a href="https://github.com/framework-one/fw1/issues?q=is%3Aissue+is%3Aclosed+milestone%3A3.1">Issues Closed</a></li>
<li><a href="https://github.com/framework-one/fw1/pulls?q=is%3Apr+is%3Aclosed+milestone%3A3.1">Pull Requests Merged</a></li>
<p>At this point, release 3.1 is &ldquo;feature complete&rdquo; and only bug fixes will be included between now and the &ldquo;gold&rdquo; release. 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.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.1 Beta 2 Available!]]></title>
    <link href="http://framework-one.github.io/blog/2015/06/20/fw1-3-1-beta-2/"/>
    <updated>2015-06-20T00:59:49-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/06/20/fw1-3-1-beta-2</id>
    <content type="html"><![CDATA[<p>The second beta version of FW/1 3.1 is available for testing. Whilst this is a minor bug fix and enhancement release, it now includes the first major rewrite of AOP/1. Documentation will follow shortly. Massive thanks to Daniel Budde for the rewrite! You can <a href="https://github.com/framework-one/fw1/releases/tag/v3.1-beta2">download FW/1 3.1 Beta 2</a> from GitHub, as well as read the full release notes there.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.1 Beta 1 Available!]]></title>
    <link href="http://framework-one.github.io/blog/2015/05/14/fw1-3-1-beta-1/"/>
    <updated>2015-05-14T22:40:49-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/05/14/fw1-3-1-beta-1</id>
    <content type="html"><![CDATA[<p>The first beta version of FW/1 3.1 is available for testing. This is a minor bug fix and enhancement release. You can <a href="https://github.com/framework-one/fw1/releases/tag/v3.1-beta1">download FW/1 3.1 Beta 1</a> from GitHub, as well as read the full release notes there.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 2.5.2 & 2.2.3 - Important Updates!]]></title>
    <link href="http://framework-one.github.io/blog/2015/05/09/fw1-2-5-1-2-2-2-important/"/>
    <updated>2015-05-09T22:20:49-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/05/09/fw1-2-5-1-2-2-2-important</id>
    <content type="html"><![CDATA[<p>The thread safety issue affecting SES URLs and routes in FW/1 3.0 has been backported to the 2.2.x and 2.5.x releases so if you believe you are seeing incorrectly routed requests on either of those releases, you can update to the appropriate patch release:</p>
<li><a href="https://github.com/framework-one/fw1/releases/tag/v2.5.2">download FW/1 2.5.2</a> to replace Release 2.5.1 or 2.5</li>
<li><a href="https://github.com/framework-one/fw1/releases/tag/v2.2.3">download FW/1 2.2.3</a> to replace Release 2.2.2, 2.2.1 or 2.2</li>
<p>These include a context root fix for 2.5.1 and 2.2.2.</p>
<p>If you are on an earlier release of FW/1 and believe you are seeing the issue that is fixed in this patch, please post on the FW/1 mailing list (I&rsquo;d rather not backport this patch any further &mdash; I&rsquo;d rather you upgraded!).</p>
<p>Once again, thank you to David Sedeño who highlighted this critical issue!</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.0.2 - Important Update!]]></title>
    <link href="http://framework-one.github.io/blog/2015/05/09/fw1-3-0-1-important/"/>
    <updated>2015-05-09T22:00:49-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/05/09/fw1-3-0-1-important</id>
    <content type="html"><![CDATA[<p>If you are using SES URLs or routes with FW/1 3.0 you should <a href="https://github.com/framework-one/fw1/releases/tag/v3.0.2">download FW/1 3.0.2</a> and update your applications as soon as possible, to address a thread safety issue in the way that <code>CGI.PATH_INFO</code> was handled in FW/1 3.0. This is an update to 3.0.1 and includes a context root fix.</p>
<p>The symptoms you might see include incorrectly routed requests under load.</p>
<p>Thank you to David Sedeño who highlighted this critical issue!</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.1 Begins...]]></title>
    <link href="http://framework-one.github.io/blog/2015/03/21/fw1-3-1-begins/"/>
    <updated>2015-03-21T14:30:49-07:00</updated>
    <id>http://framework-one.github.io/blog/2015/03/21/fw1-3-1-begins</id>
    <content type="html"><![CDATA[<p>I released FW/1 3.0 about a month ago and now it&rsquo;s time to get started on the 3.1 release.<!-- more --></p>
<p>FW/1 3.1 will be primarily a maintenance release. You can read the <a href="https://github.com/framework-one/fw1/milestones/3.1">current list of changes slated for FW/1 3.1</a> on the GitHub issues page. Depending on how long it takes to get 3.1 done, additional issues may be added. And, of course, some of these issues may be slipped to 3.5 (currently represented by the <a href="https://github.com/framework-one/fw1/tree/clojure">Clojure branch of FW/1</a> in the GitHub repo and the <a href="https://github.com/framework-one/fw1/milestones/3.5">short list of FW/1 3.5 issues</a>).</p>
<p>Starting with release 3.0, the <a href="http://framework-one.github.io/documentation/">FW/1 documentation</a> will be versioned and the top-level page will always represent the latest version in development. You can read the <a href="http://framework-one.github.io/documentation/3.0/">FW/1 3.0 documentation</a> separately already. The sidebar will always show two releases (develop and master) fully linked &ndash; older versions will be listed in future, with just a link to the index page.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.0 Released!]]></title>
    <link href="http://framework-one.github.io/blog/2015/02/24/fw1-3-0-released/"/>
    <updated>2015-02-24T09:30:49-08:00</updated>
    <id>http://framework-one.github.io/blog/2015/02/24/fw1-3-0-released</id>
    <content type="html"><![CDATA[<p>I&rsquo;m pleased to announce that after lots of user testing and almost no issues found, the Gold Release of <a href="https://github.com/framework-one/fw1/releases/tag/v3.0">FW/1 3.0</a> is now available!<!-- more --></p>
<p>About two and a half weeks ago I released <a href="http://framework-one.github.io/blog/2015/02/06/fw1-3-0-rc-2-available/">FW/1 3.0 RC 2</a> and only one minor issue was reported (an inconsistency between <code>buildURL()</code> and <code>buildCustomURL()</code> regarding how <code>baseURL</code> was handled). That has been fixed, along with the addition of a new extension point for DI/1 (<code>metadata()</code>).</p>
<p>You can see a <a href="https://github.com/framework-one/fw1/issues?milestone=13&amp;q=is%3Aclosed">full list of issues fixed in FW/1 for 3.0</a> and a <a href="https://github.com/framework-one/di1/issues?milestone=1&amp;q=is%3Aclosed">full list of issues fixed in DI/1 1.0</a> on GitHub. This represents the official release of DI/1 1.0 as well.</p>
<p>Thank you to everyone who has contributed to the 3.0 release &ndash; it&rsquo;s been a long time in the making! Particular thanks go to Nando Breiter for migrating the DI/1 documentation from the old wiki to the new FW/1 website. Also thanks to John Berquist, Ryan Guill, Cameron Childress, and Adam Tuttle for you code contributions and everyone who tested prerelease builds of FW/1 and reported issues and made suggestions! Thank you!</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.0 RC 2 Available]]></title>
    <link href="http://framework-one.github.io/blog/2015/02/06/fw1-3-0-rc-2-available/"/>
    <updated>2015-02-06T20:21:49-08:00</updated>
    <id>http://framework-one.github.io/blog/2015/02/06/fw1-3-0-rc-2-available</id>
    <content type="html"><![CDATA[<p>About two weeks ago I released <a href="http://framework-one.github.io/blog/2015/01/24/fw1-3-0-rc-1-available/">FW/1 3.0 RC 1</a> and the only real bug persisting at that point was related to <a href="https://github.com/framework-one/fw1/issues/283">DI/1 dotted path deduction</a>.</p>
<p>I think that bug is finally squashed, based on early testing by some users that had encountered the bug, so the second <a href="https://github.com/framework-one/fw1/releases/tag/v3.0-rc2">Release Candidate build</a> of FW/1 3.0 is now available!<!-- more --></p>
<p>In addition to fixing that DI/1 bug, the only other change since RC 1 is some cleanup of the <code>examples</code> folder. That means this RC is almost certainly going to be gold candidate for the final 3.0 release.</p>
<p>Please download and test this version and report any issues you find. I&rsquo;d like to cut the final 3.0 release fairly soon, so I can merge <code>develop</code> to <code>master</code> and start planning FW/1 3.5.</p>
]]></content>
    <title type="html"><![CDATA[Lucee and FW/1]]></title>
    <link href="http://framework-one.github.io/blog/2015/01/29/lucee-fw1/"/>
    <updated>2015-01-29T13:30:49-08:00</updated>
    <id>http://framework-one.github.io/blog/2015/01/29/lucee-fw1</id>
    <content type="html"><![CDATA[<p>Today saw the announcement of the <a href="http://lucee.org">Lucee Association Switzerland</a> and the release of a new open source CFML engine: <a href="http://lucee.org/downloads.html">Lucee 4.5.0</a>.</p>
<p>For background on the new engine and the association behind it, read <a href="http://blog.adamcameron.me/2015/01/lucee.html">Adam Cameron&rsquo;s blog post with Q&amp;A</a> about the launch.</p>
<p>I&rsquo;ve already migrated all my local test environments to Lucee and can report that FW/1 (and DI/1 and cfmljure) all run beautifully on it &ndash; and it will be my primary test environment for future development of the FW/1 family going forward.</p>
<p>I&rsquo;ve also migrated my local dev environment for World Singles over to Lucee and that went pretty smoothly too (I encountered just two issues &ndash; both minor, one already fixed in Lucee&rsquo;s master repository).</p>
<p>The <a href="https://bitbucket.org/lucee/lucee/wiki/Home">Lucee wiki</a> has information about downloading and installing Lucee, as well as building Lucee from source, and how to migrate from Railo to Lucee (hint: it&rsquo;s really easy &ndash; stop the server, remove <code>railo.jar</code>, add <code>lucee.jar</code>, start the server).</p>
<p>Have fun with Lucee!</p>
]]></content>
    <title type="html"><![CDATA[FW/1 & Clojure Sitting in Tree]]></title>
    <link href="http://framework-one.github.io/blog/2015/01/25/fw1-clojure-sitting-in-a-tree/"/>
    <updated>2015-01-25T13:30:49-08:00</updated>
    <id>http://framework-one.github.io/blog/2015/01/25/fw1-clojure-sitting-in-a-tree</id>
    <content type="html"><![CDATA[<p>Anyone following my tech trajectory will know that, after starting to learn Clojure in 2010, I&rsquo;ve moved increasingly away from CFML and toward Clojure. In 2014, my team decided that Clojure would be our official primary language and all new development would happen there instead of in CFML. We still have a lot of CFML code in production &ndash; about 90kloc &ndash; but we consider it &ldquo;legacy code&rdquo; at this point. Most of that CFML code is a large ColdBox app that we built about five years ago (technically it&rsquo;s three ColdBox apps but they share a lot of code). Our application Model has been slowly moving to Clojure so that we can reuse that code in new applications we&rsquo;re building in Clojure. We&rsquo;ve also been building new apps with FW/1 (and reusing both our CFML code and our Clojure code). We still like CFML as a templating language for views and our controllers &ndash; in our FW/1 apps at least &ndash; are often mostly just &ldquo;glue&rdquo; code that lets us call into our Clojure model code.<!-- more --></p>
<p>I&rsquo;ve talked in passing on the FW/1 mailing list about the possibility of deeper integration with Clojure and I recently published <a href="https://github.com/framework-one/cfmljure/releases/tag/v0.1.0">cfmljure 0.1.0</a> &ndash; which I&rsquo;ll be blogging about shortly &ndash; and so the topic came up again on the mailing list about this integration. I&rsquo;d been thinking about how to write controllers in Clojure so that you could have a FW/1 app that used CFML for the views &ndash; where it excels as a templating language &ndash; and Clojure for the controllers and the model, leveraging the expressive power and immutable safety for all your business logic.</p>
<p>Over the last few days, I created a fork of FW/1 3.0 that included cfmljure and built a proof of concept of Clojure controllers. You can take a look at the <a href="https://github.com/framework-one/fw1/tree/clojure/examples/6helloclojure">FW/1 example with Clojure controllers</a> on the <code>clojure</code> branch of the FW/1 repo. I created the project using Leiningen (Clojure&rsquo;s build tool) and then added <code>Application.cfc</code>, <code>index.cfm</code>, and the <code>views/</code> tree. Then I wrote the <code>controllers/main.clj</code> file (in <code>src/hello</code>) and the <code>controllers_test.clj</code> test file (in <code>test/hello</code>). Unit testing is built in, so you can run <code>lein test</code> to see the results. Then I refactored the Clojure code (creating the separate <code>greet.clj</code> file) and added a &ldquo;service&rdquo; in Clojure just for fun. The FW/1 app uses <code>framework.ioclj</code> &ndash; a extended version of DI/1 that uses cfmljure &ndash; to auto-discover the Clojure code (and the CFML code &ndash; you can mix&#8217;n&#8217;match) and wraps the Clojure controllers in <code>framework.cljcontroller</code> (to adapt to Clojure&rsquo;s pure function calling convention, and to handle some FW/1-specific functionality). The CFML views are run as usual (and if you look in <code>views/main/default.cfm</code> you&rsquo;ll see a call to the Clojure &ldquo;service&rdquo; via the bean factory: <code>getBeanFactory().getBean("greeterService").greetings("Earthling!")</code>).</p>
<p>I&rsquo;m rather excited about this because it means we&rsquo;ll have a way, at work, to further migrate our model code from CFML to Clojure, while maintaining &ldquo;legacy&rdquo; CFML code alongside, <em>right there in the same FW/1 application!</em></p>
<p>This won&rsquo;t be part of FW/1 3.0. Instead it will stay on the <code>clojure</code> branch until release 3.0 is out (<code>develop</code> will be merged to <code>master</code> for that), but it will be part of FW/1 3.5 which will be the next release. That way it can get some field testing in production as well as some polish and some documentation love. Stay tuned!</p>
<p>p.s. Right now cfmljure only runs on Railo. The CFML code itself could be made portable enough to run on ColdFusion but the real problem is interop with Java/Clojure: ColdFusion thinks 42 is a string and so you need to do a lot of string-to-number conversions to interact with Clojure through cfmljure. I haven&rsquo;t used ColdFusion for over five years &ndash; just Railo &ndash; so I don&rsquo;t have much incentive, but if you feel inclined to send a Pull Request with changes to make cfmljure ColdFusion-compatible&hellip;</p>
<p>p.p.s. cfmljure now runs on Adobe ColdFusion 11, Lucee, and Railo! Thanks to Andrew Myers for tackling ColdFusion support.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.0 RC 1 Available]]></title>
    <link href="http://framework-one.github.io/blog/2015/01/24/fw1-3-0-rc-1-available/"/>
    <updated>2015-01-24T22:21:49-08:00</updated>
    <id>http://framework-one.github.io/blog/2015/01/24/fw1-3-0-rc-1-available</id>
    <content type="html"><![CDATA[<p>FW/1 3.0 has been in beta testing since August 2014 and lots of people are already running in production so I figured it was time to push out the first <a href="https://github.com/framework-one/fw1/releases/tag/v3.0-rc1">Release Candidate build</a>.</p>
<p>The main focus of RC 1 has been bug fixes. Only a small number of functional enhancements have been added (notably <code>getEnvVar()</code> to retrieve the value of a system environment variable which can be useful during environment control processing).<!-- more --> Some deprecated features have been removed:</p>
<li><code>getRC()</code> and <code>getRCValue()</code> have been removed, along with the configuration flag that had been enabling them. They were a hasty addition at the end of the 2.5 cycle and they were a mistake &ndash; if you&rsquo;re using them, you&rsquo;re doing something wrong!</li>
<li><code>org.corfield.framework</code> is no longer supported &ndash; use <code>framework.one</code> instead. It was always a questionable choice of file path for the framework and I&rsquo;ve been tempted to change it several times. The 3.0 cycle deprecated it and moved the framework CFC to the <code>/framework</code> folder, where DI/1 has lived since the 2.5 cycle. This is probably a <strong>breaking change</strong> unless you&rsquo;ve been using prerelease builds of 3.0 and have already eliminated the deprecation warnings!</li>
<p>In addition, AOP/1 is no longer bundled with FW/1. It&rsquo;s not ready for primetime yet so I didn&rsquo;t want to include it in the 3.0 release. It got a lot of work between Alpha 1 and Beta 1 but additional bugs and some hard problems came up in testing. It&rsquo;s still available on the <code>aop1</code> branch if you want to experiment with it (and help find and fix more bugs in it!).</p>
<p>As part of the preparation for RC 1, all of the documentation has been reviewed and updated and DI/1&rsquo;s documentation is now <a href="http://framework-one.github.io/documentation/using-di-one.html">part of the main documentation site</a>. Big thanks go to Nando Breiter for bringing that across from the old wiki in the standalone DI/1 repo. Code contributors to RC 1 include: John Berquist, Ryan Guill, Cameron Childress. Thank you!</p>
<p>At this point, only bug fixes will be considered before FW/1 3.0 goes &ldquo;gold&rdquo; and given the long period of testing so far on Beta 1, that final release shouldn&rsquo;t be too far away.</p>
<p>Oh, and if you go to <a href="http://fw1.riaforge.org">FW/1&rsquo;s page on RIAForge</a>, you&rsquo;ll see that 3.0 RC 1 is the default download now, instead of 2.5.</p>
]]></content>
    <title type="html"><![CDATA[Cfmljure Release 0.1.0]]></title>
    <link href="http://framework-one.github.io/blog/2015/01/23/cfmljure-0-1-0/"/>
    <updated>2015-01-23T13:30:49-08:00</updated>
    <id>http://framework-one.github.io/blog/2015/01/23/cfmljure-0-1-0</id>
    <content type="html"><![CDATA[<p>I started cfmljure back in 2010, a few months after I started to learn Clojure, as a way to run Clojure code inside a CFML application. That early version worked &ndash; we&rsquo;ve been using it in at World Singles since mid-2011 to integrate Clojure into our large ColdBox application, and updated versions of cfmljure have been in very heavy production usage since May 2012.<!-- more --> Those early versions were pretty clunky to setup though, since you needed to mess with the classpath of your CFML engine (or at least the container on which you ran it &ndash; Tomcat, in our case) and you needed to copy all your third-party library dependencies into the <code>WEB-INF/lib</code> folder (and restart your container if you changed your dependencies).</p>
<p>When Clojure 1.6 came out (March 2014), it introduced a new API for embedding Clojure inside other JVM applications. I&rsquo;d been relying on an unsupported API so I wanted to move to the new API as soon as possible. I ran into problems with classpath handling so I put it on the back burner for a while. One of the things that bothered me about the earlier cfmljure was that you had to do so much configuration and manual copying of libraries. Leiningen handles all this for you in Clojure and I wanted things to be that slick for cfmljure. I experimented with some CFML code that executed Leiningen to retrieve the classpath and I had some success, but not enough to create a reliable version that could be used in our app at work.</p>
<p>This past week, I decided to have another run at it, using a different approach to manipulating the classpath in my running CFML application:</p>
<pre><code>// extend the classloader - not at all sketchy, honest!
var threadProxy = createObject( "java", "java.lang.Thread" );
var appCL = threadProxy.currentThread().getContextClassLoader();
var urlCLProxy = createObject( "java", "java.net.URLClassLoader" );
var addURL = urlCLProxy.getClass().getDeclaredMethod( "addURL", __classes( "URL", 1, "java.net" ) );
addUrl.setAccessible( true ); // hack to make it callable
for ( var newURL in urls.toArray() ) {
    addURL.invoke( appCL, [ newURL ] );
</code></pre>
<p>I gleaned the principle of this from time spent on Google and StackOverflow and several snippets of Java code that did this same thing. It uses Java Reflection to get a handle on <code>URLClassLoader.addURL()</code> and change its access to public so that it can be called by code that doesn&rsquo;t extend the <code>URLClassLoader</code> class. This got me past the previous blocking point and I was able to complete the rewrite of that earlier version of cfmljure to use the new Clojure 1.6 API and also leverage Leiningen to avoid that configuration and manual copying.</p>
<p>I present: <a href="https://github.com/framework-one/cfmljure/releases/tag/v0.1.0">cfmljure Release 0.1.0</a>! An easy-to-use way to embed a Clojure project into your CFML application (running on Lucee or Railo).</p>
<p>The documentation is in the <a href="https://github.com/framework-one/cfmljure/blob/master/README.md">cfmljure README</a> on Github but the basic flow is as follows:</p>
<li>Create a Clojure project with Leiningen: <code>lein new myproject</code></li>
<li>Create an instance of cfmljure pointing at that project folder: <code>var clj = new cfmljure("/path/to/myproject");</code></li>
<li>Install Clojure namespaces into a struct (or a scope): <code>clj.install("clojure.core,myproject.core",this);</code></li>
<li>Call Clojure code: <code>this.clojure.core.println("Hello World!");</code></li>
<p>That&rsquo;s about as simple as it gets!</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.0 Beta 1 Available]]></title>
    <link href="http://framework-one.github.io/blog/2014/08/18/fw1-3-0-beta-1-available/"/>
    <updated>2014-08-18T11:21:49-07:00</updated>
    <id>http://framework-one.github.io/blog/2014/08/18/fw1-3-0-beta-1-available</id>
    <content type="html"><![CDATA[<p>Just over four weeks ago, I released <a href="http://framework-one.github.io/blog/2014/07/20/fw1-3-0-alpha-1-available-for-testing/">FW/1 3.0 Alpha 1</a> and declared it <em>feature complete</em>. There were some big changes in that release and, in particular, some long-standing features were removed (after being deprecated in FW/1 2.5) and some recently-introduced features were also deprecated. Today I am releasing the first Beta version which includes bug fixes and usability enhancements, focusing primarily on DI/1 and AOP/1.<!-- more --></p>
<p>You can <a href="https://github.com/framework-one/fw1/releases/tag/v3.0-beta1">download FW/1 3.0 Beta 1 from Github</a> and that release page has a link to <a href="https://github.com/framework-one/fw1/issues?milestone=13&amp;page=1&amp;state=closed">the complete list of closed tickets in FW/1 3.0 Beta 1</a> and <a href="https://github.com/framework-one/di1/issues?milestone=1&amp;page=1&amp;state=closed">closed tickets in DI/1 that are for FW/1 3.0</a>. Note that those issues are only fixed in the FW/1 repository, not the DI/1 repository, but they will be backported later on.</p>
<h2>DI/1 and AOP/1 come of age</h2>
<p>As indicated above, the focus of Beta 1 has been on cleaning up DI/1 and AOP/1 to get them to a &ldquo;1.0&rdquo; release status as part of FW/1 3.0. Going forward, the DI/1 and AOP/1 repositories will only get updated with released versions and will be stripped down to minimal examples for those who wish to use them standalone. Future development (including issues and test cases etc) will all be done in the FW/1 repository.</p>
<p>DI/1 has been enhanced in this release to provide some features that will help developers migrating from ColdSpring (or who are looking for some of ColdSpring&rsquo;s more advanced features in DI/1).</p>
<p>AOP/1 has been rewritten to better integrate with DI/1 and ensure that injected beans are intercepted (the <code>beanProxy.cfc</code> needed only minor tweaks and it does the heavy lifting of interception).</p>
<p>Here is the full list of changes in DI/1 and AOP/1 (since Alpha 1):</p>
<li>Dotted path deduction rewritten / improved <a href="https://github.com/framework-one/di1/issues/61">di1/#61</a>. There were a number of situations where DI/1 was unable to figure out a dotted component path for CFCs identified through relative folder paths, especially outside the primary webroot of an application. This should be addressed now!</li>
<li>New option <code>omitDirectoryAliases</code> &ndash; default <code>false</code> <a href="https://github.com/framework-one/di1/issues/64">di1/#64</a>. Set this <code>true</code> if you want to suppress the directory-based aliases that DI/1 creates (e.g., <code>beans/user.cfc</code> => <code>userBean</code>). This will enforce uniqueness of bean names (since the suffix will no longer differentiate beans with the same name in different folders).</li>
<li>IIS web server mapping case sensitivity <a href="https://github.com/framework-one/di1/issues/65">di1/#65</a>. A bug fix for an annoying edge case caused by IIS being case sensitive in a situation that caused hard-to-debug errors from DI/1.</li>
<li>AOP/1 now handles intercepted methods that return null <a href="https://github.com/framework-one/fw1/issues/264">#264</a>. Self-explanatory.</li>
<li>DI/1 now accepts a load listener as part of its configuration <a href="https://github.com/framework-one/fw1/issues/273">#273</a>. This was added to allow load listeners to be added easily via <code>diConfig</code> when using FW/1. A load listener is the recommended way to declare new beans, add aliases and additional beans and set up factory beans/methods (see next item).</li>
<p>The following DI/1 setups are now equivalent:</p>
<pre><code>var bf1 = new framework.ioc( "..." );
bf1.onLoad( myListener );
var bf2 = new framework.ioc( "...", { loadListener = myListener } );
</code></pre>
<li>DI/1 now supports factory beans / factory methods <a href="https://github.com/framework-one/fw1/issues/274">#274</a>. The new API <code>factoryBean()</code> allows you to specify that a bean should be obtained from another bean &ndash; the <em>factory bean</em> &ndash; by calling a specified method &ndash; the <em>factory method</em> &ndash; with optionally specified arguments, and optional bean value overrides (similar to the <code>declareBean()</code> API).</li>
<p>Here are some examples:</p>
<pre><code>bf.factoryBean( "a1Bean", "myFactory", "theMethod" );
// a1Bean = bf.getBean("myFactory").theMethod();
bf.factoryBean( "a2Bean", "yourFactory", "createIt", [ "dsn" ] );
// a2Bean = bf.getBean("yourFactory").createIt( bf.getBean("dsn") );
bf.factoryBean( "a3Bean", "warehouse", "builder", [ "dsn", "config" ],
    { dsn = "myDB" } );
// a3Bean = bf.getBean("warehouse").builder( "myDB", bf.getBean("config") );
</code></pre>
<li>DI/1 now supports a post-injection <em>init-method</em> like ColdSpring <a href="https://github.com/framework-one/fw1/issues/275">#275</a>. A new configuration option <code>initMethod</code> allows you to specify a no-argument method that DI/1 should attempt to call on all managed beans after all of their dependencies have been injected. This allows beans to perform additional configuration that requires access to their injected dependencies, which cannot be performed in a constructor. You can thank Daniel Budde II for this feature being added (and for spurring me to finally add factory beans/methods which I&rsquo;d been thinking about for a while)!</li>
<li>AOP/1 now intercepts injected beans <a href="https://github.com/framework-one/fw1/issues/277">#277</a>. This was the rewrite of AOP/1 to hook into DI/1&rsquo;s <code>resolveBean()</code> method via a new <code>setupInitMethod()</code> extension point (which will make additional extensions to DI/1 easier). Previously AOP/1 only intercepted beans obtained directly via <code>getBean()</code>. Thank you to Daniel Budde II for identifying this issue and providing a test case to help debug and verify the new behavior.</li>
<li>DI/1 no longer resolves beans multiple times <a href="https://github.com/framework-one/fw1/issues/279">#279</a>. This was a performance issue but previously harmless. With the enhancements to AOP/1, this introduced several bugs (hopefully all fixed now!).</li>
<h2>FW/1 bug fixes and enhancements</h2>
<p>Here are the changes in FW/1 itself since Alpha 1:</p>
<li>Controllers are reloaded after the bean factory is updated <a href="https://github.com/framework-one/fw1/issues/276">#276</a>. Previously, FW/1 cached controllers and recreating the bean factory was not sufficient to pick up changes in controller files. Now, when you call <code>setBeanFactory()</code>, the controller cache is cleared so controllers will be reloaded and any changes will be picked up (regardless of whether controllers are managed by FW/1 or DI/1).</li>
<h2>The road to gold</h2>
<p>The next milestone should be Release Candidate 1 and only bug fixes are likely to be considered at this point, no new features or enhancements, unless they are required to make the Beta feature set fully usable. If all goes well, RC1 should be released in about 3-4 weeks, and the <em>gold</em> 3.0 release about 3-4 weeks after that (late September / early October).</p>
<p>Note that <code>org.framework.corfield</code> is a deprecated path for FW/1 &ndash; it has moved to <code>framework.one</code> &ndash; and whilst it is supported during the 3.0 prerelease builds, it will be removed in the gold release. Similarly, as noted in the Alpha 1 blog post, <code>getRC()</code> and <code>getRCValue()</code> are deprecated and will also be removed in the gold release.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 3.0 Alpha 1 Available for Testing!]]></title>
    <link href="http://framework-one.github.io/blog/2014/07/20/fw1-3-0-alpha-1-available-for-testing/"/>
    <updated>2014-07-20T18:14:24-07:00</updated>
    <id>http://framework-one.github.io/blog/2014/07/20/fw1-3-0-alpha-1-available-for-testing</id>
    <content type="html"><![CDATA[<p>I consider FW/1 3.0 to be <em>feature complete</em> at this point so I am releasing Alpha 1 for testing. I expect people to run into a few bugs &ndash; this release has some big changes in it, compared to the 2.x release stream &ndash; and it&rsquo;s possible that new feature requests will crop up during alpha testing, but everything I wanted to change is in place.<!-- more --></p>
<p>You can <a href="https://github.com/framework-one/fw1/releases/tag/v3.0-alpha1">download FW/1 3.0 Alpha 1 from Github</a> and that release page has a link to <a href="https://github.com/framework-one/fw1/issues?milestone=13&amp;page=1&amp;state=closed">the complete list of closed tickets in FW/1 3.0 Alpha 1</a> although I&rsquo;m going to summarize the most important ones in this blog post.</p>
<h2>Features Removed</h2>
<p>First and foremost, some features that have been part of FW/1 from the early days have been removed. These features were deprecated in FW/1 2.5 as a migration path so I would strongly advise anyone still on FW/1 2.2.1 (or earlier) to upgrade to 2.5 in preparation for the (breaking) changes in 3.0!</p>
<p>These features include the <code>service()</code> API call and the <code>start*()</code> and <code>end*()</code> item handlers within controllers, as well as global references to <code>rc</code> (where it was not passed as an argument or made available in a view automatically). You can read more about the deprecation (and now removal) of these features in <a href="http://framework-one.github.io/blog/2014/05/25/fw1-2-5-is-released/">the release announcement for FW/1 2.5</a> on this blog. Management of services via a bean factory, with property-based injection, and direct invocation has long been considered a much better way to interact with services than using the &ldquo;service queue&rdquo; that FW/1 originally provided.</p>
<p>In addition, the recently added <code>getRC()</code> and <code>getRCValue()</code> API calls &ndash; added in FW/1 2.5 during the deprecation of global references to <code>rc</code> &ndash; have been deprecated <em>and will be removed in the final FW/1 3.0 release</em>. They were hastily added and they were unnecessary. In this alpha release, their use will trigger an exception explaining what to use instead. You can add:</p>
<pre><code>framework.enableLegacyRCAccessors = true
</code></pre>
<p>to your configuration while you update your code (this will suppress the exception but still write a message to your application server&rsquo;s console output &ndash; just as the deprecation process did in FW/1 2.5).</p>
<h2>Automatic Bean Factory Usage</h2>
<p>The other big change in this 3.0 release is that DI/1 (and AOP/1) is fully integrated. FW/1 itself moves from <code>org.corfield.framework</code> to <code>framework.one</code> alongside <code>framework.ioc</code> (DI/1), <code>framework.aop</code> (AOP/1), and some helper CFCs. <code>org.corfield.framework</code> still exists but will issue a deprecation warning if it is used. It will be removed in the final 3.0 release.</p>
<p>You can still place the FW/1 CFCs anywhere you want but if you move DI/1, you&rsquo;ll need to tell FW/1 where to find it &ndash; see below.</p>
<p>Previously, it was expected that you create a bean factory in your <code>Application.cfc</code> <code>setupApplication()</code> function and call FW/1&rsquo;s <code>setBeanFactory()</code> API to tell the framework about it. For some time, he conventional path to your <strong>Model</strong> CFCs has been <code>/model/beans</code> for your transient beans (domain objects) and <code>/model/services</code> for your singleton services (and perhaps <code>/model/gateways</code> for any data gateways, although those could just as easily live in your services folder too). That means you nearly always had the following code in <code>setupApplication()</code>:</p>
<pre><code>var bf = new framework.ioc( "model" );
setBeanFactory( bf );
</code></pre>
<p>Or, if you also managed your controllers this way, you may have had:</p>
<pre><code>var bf = new framework.ioc( "model,controllers" );
bf.addBean( "fw", this );
setBeanFactory( bf );
</code></pre>
<p>The <code>addBean()</code> call ensures that the bean factory knows <code>fw</code> is an alias for your bean factory so it will be available to any controller <code>init( any fw )</code> methods when they are constructed.</p>
<p>If you use subsystems, you probably had something similar in your <code>setupSubsystem()</code> function (and hopefully you set the default bean factory as a parent for each subsystem bean factory).</p>
<p>Now, FW/1 does this for you automatically. There are new configuration options to control the details, but the default cases <em>should just work</em> and you can remove your bean factory creation code from your <code>setupApplication()</code> function. Those options are:</p>
<li><code>diEngine</code> &ndash; the type of the dependency injection engine: FW/1 knows about <strong>&ldquo;di1&rdquo;</strong>, <strong>&ldquo;aop1&rdquo;</strong>, and <strong>&ldquo;wirebox&rdquo;</strong>. The default is <strong>&ldquo;di1&rdquo;</strong>. You can also specify <strong>&ldquo;none&rdquo;</strong> to suppress the automatic bean factory machinery and <strong>&ldquo;custom&rdquo;</strong> if you want to tell FW/1 to use your own bean factory (see below). Note that ColdSpring is deliberately <em>not supported</em> as it is no longer maintained by anyone and has not been updated in years.</li>
<li><code>diComponent</code> &ndash; the default location of the bean factory CFC. For DI/1, this is <code>framework.ioc</code>; for AOP/1, this is <code>framework.aop</code>; and for WireBox, this is <code>framework.WireBoxAdapter</code>. If you move these files elsewhere, or setup a different mapping for them, set <code>diComponent</code> to that new location. If <code>diEngine</code> is <strong>&ldquo;custom&rdquo;</strong>, you can set <code>diComponent</code> to the dotted path of your bean factory for FW/1 to use it automatically.</li>
<li><code>diLocations</code> &ndash; the set of folders that DI/1, AOP/1, or WireBox will scan for CFCs. The default is <strong>&ldquo;model,controllers&rdquo;</strong> &ndash; note the relative paths! If you have these folders elsewhere (i.e., not relative to the application root), then you&rsquo;ll need to specify <code>diLocations</code>, e.g., as <code>"/model,/controllers"</code> or <code>"/myapp/model,/myapp/controllers"</code> or something similar.</li>
<li><code>diConfig</code> &ndash; additional configuration passed to DI/1, AOP/1, WireBox, or your custom bean factory. Specifically, this is the second argument to the constructor for DI/1 or AOP/1, and the <code>properties</code> argument to the constructor for WireBox, or the single argument to the constructor for your own bean factory. By default, it is an empty struct.</li>
<h2>Additional Features</h2>
<p>In addition to the two major changes listed above, there are a number of minor enhancements compared to FW/1 2.5:</p>
<li><code>isUnhandledRequest( string targetPath )</code> &ndash; a new API that you can override to tell FW/1 not to handle certain requests. By default, this returns <strong>true</strong> for certain file extensions and certain paths, as specified by the <code>unhandledExtensions</code> and <code>unhandledPaths</code> configuration values but you can choose to override this completely, or still call <code>super.isUnhandledRequest(targetPath)</code> and add additional conditions of your own.</li>
<li><code>redirectCustomURL( string uri, string preserve = 'none', statusCode = '302' )</code> &ndash; a new API that uses <code>buildCustomURL()</code> to construct a URL for a redirect.</li>
<li><code>buildCustomURL()</code> &ndash; now supports variable substitution: if <code>:varname</code> is present in the URI passed in and <code>rc.varname</code> exists and is a simple value, then that value will be substituted into the returned URL. To avoid confusion with subsystem paths, <code>:varname</code> will only be recognized if it follows one of: <code>/</code>, <code>?</code>, <code>=</code>, <code>&amp;</code>.</li>
<li><code>setLayout()</code> &ndash; now accepts an optional second argument, a <strong>boolean</strong>, that let&rsquo;s you tell FW/1 to automatically suppress any further layouts. This removes the need to specify <code>request.layouts = false</code> in your layout file.</li>
<li>Both DI/1 and FW/1 now try very hard to avoid attempting to autowire FW/1 itself (or the Application.cfc based on it, which acts as a global controller in a FW/1 application).</li>
]]></content>
    <title type="html"><![CDATA[FW/1 2.5 Is Released!]]></title>
    <link href="http://framework-one.github.io/blog/2014/05/25/fw1-2-5-is-released/"/>
    <updated>2014-05-25T23:13:39-07:00</updated>
    <id>http://framework-one.github.io/blog/2014/05/25/fw1-2-5-is-released</id>
    <content type="html"><![CDATA[<p>This is a migration release to pave the way for breaking changes in Release 3.0. All examples have been updated to latest best practices and now use cfcscript exclusively. Examples use DI/1 0.5.0 to manage all beans and services (as <code>framework.ioc</code>), and no longer rely on start/end actions or the <code>service()</code> method.<!-- more --></p>
<p>As always, FW/1 can be downloaded from the <a href="http://fw1.riaforge.org">FW/1 page on RIAForge</a>. Release 2.5 is now the latest stable release of this framework, as it approaches its fifth birthday!</p>
<p>For a full list of all tickets closed in Release 2.5: <a href="https://github.com/framework-one/fw1/issues?milestone=14&amp;page=1&amp;state=closed">https://github.com/framework-one/fw1/issues?milestone=14&amp;page=1&amp;state=closed</a></p>
<h2>Migration from 2.2.1</h2>
<p>The <code>service()</code> call has been deprecated, as have start/end action items. Global access to <code>rc</code> in <code>Application.cfc</code> has also been deprecated. If you just drop 2.5 into your setup and you rely on these features, you&rsquo;ll get exceptions explaining how to enable these features for backward compatibility, namely add the following to your framework configuration:</p>
<pre><code>enableGlobalRC = true,
suppressServiceQueue = false
</code></pre>
<p>The ability to enable the implicit service calls is still present via:</p>
<pre><code>suppressImplicitService = false
</code></pre>
<p>but, like the other two options, defaults to disallowing the deprecated feature.</p>
<p>If you enable these deprecated features, you will no longer get exceptions using them, but you will see deprecation warnings in your application server&rsquo;s console log. This is to remind you to update your code in preparation for 3.0 later this year!</p>
<p><em>Please note that Release 3.0 will completely remove these backward compatibility options &ndash; and the associated deprecated features. In addition, <code>org.corfield.framework</code> will move to <code>framework.one</code> in Release 3.0, alongside <code>framework.ioc</code>.</em></p>
]]></content>
    <title type="html"><![CDATA[FW/1 2.2 Released!]]></title>
    <link href="http://framework-one.github.io/blog/2013/12/18/fw1-2-2-released/"/>
    <updated>2013-12-18T22:34:03-08:00</updated>
    <id>http://framework-one.github.io/blog/2013/12/18/fw1-2-2-released</id>
    <content type="html"><![CDATA[<p>Framework One version 2.2 is now available for production use! You can download it from the <a href="http://fw1.riaforge.org/">Framework One page on RIAForge</a>. This includes one bug fix over RC2 (interaction between <code>renderData()</code> and trace output).<!-- more --></p>
<p>The main focus of the 2.2 release is improved support for REST APIs, through the addition of <code>renderData()</code> to simplify returning JSON, XML and plain text results to the caller, as well as more sophisticated route handling via &ldquo;resource packs&rdquo; which let you define a family of related routes for a given resource type, using a shorthand notation. For more information, see this <a href="http://framework-one.github.io/blog/2013/11/03/fw1-releases-and-roadmap/">blog post about the latest FW/1 release and the roadmap</a>.</p>
<p>As noted previously, the master branch is the current stable release (2.2), and the develop branch has become the next release (2.5). 2.5 will be released next month and will be a stepping stone toward some substantial changes coming in 3.0. For more detail, read this <a href="http://framework-one.github.io/blog/2013/11/02/fw1-the-year-ahead">blog post explaining the changes coming in 2.5 and 3.0</a>.</p>
]]></content>
    <title type="html"><![CDATA[FW/1 Releases and Roadmap]]></title>
    <link href="http://framework-one.github.io/blog/2013/11/03/fw1-releases-and-roadmap/"/>
    <updated>2013-11-03T11:38:30-08:00</updated>
    <id>http://framework-one.github.io/blog/2013/11/03/fw1-releases-and-roadmap</id>
    <content type="html"><![CDATA[<p>Today I released the first <a href="https://github.com/framework-one/fw1/releases/tag/v2.2-rc1">FW/1 Version 2.2 Release Candidate</a> for testing. See below for the list of changes in this release, compared to Version 2.1. I also released a maintenance update for the old compatibility branch: <a href="https://github.com/framework-one/fw1/releases/tag/v1.3">FW/1 Version 1.3</a> (the &ldquo;Latest Release&rdquo; label is due to Github&rsquo;s view of the world, but it is the latest 1.x release). This is the version to use if you&rsquo;re on CFMX 7, CF 8, CF 9.0.0, Railo versions prior to 3.2, or OpenBD.<!-- more --></p>
<p>In addition to these two releases, I also added milestones (and dates!) for the next two FW/1 releases: 2.5 and 3.0. There are some fairly big changes coming, including some important breaking changes. I&rsquo;ll post a follow-up with more details on <strong>why</strong> these changes are coming, but you should read the <a href="https://github.com/framework-one/fw1/issues/milestones">FW/1 Roadmap</a> and start thinking about how these changes will affect you (as well as reading the next blog post, of course!).</p>
<p>As always, FW/1 wouldn&rsquo;t be possible without all the contributions from the community. This version includes contributions from John Berquist (regex caching in routes, resource packs in routes), Marco Betschart, Chris Blackwell, Peter Boughton, Will Coleda, Billy Cravens, Mark Drew, and all those who have provided feedback via the mailing list and Twitter and IM and&hellip; Thank you!</p>
<p>Here&rsquo;s a fairly complete change list for Version 2.2:</p>
<li>#198 <code>renderData()</code> added for easier REST APIs</li>
<li>#197 resource pack support added to routes for easier REST APIs</li>
<li>#195 override <code>processRoutes()</code> to customize them (<code>addRoute()</code> is deprecated)</li>
<li>#192 regex in routes are now cached for improved performance</li>
<li>#181 improve null value support (Railo compatibility)</li>
<li>#179 can use <code>onMissingMethod()</code> for <code>injectFramework()</code></li>
<li>#176 <code>buildURL()</code> now correctly supports <code>?</code> at end of action</li>
<li>#175 subsystems automatically enabled if you specify subsystem configuration</li>
<li>#170 layout suppression is now correctly reset on an exception</li>
<li>#169 ensure <code>framework.home</code> is consistent with subsystem settings</li>
<li>#168 don&rsquo;t strip additional characters from start of path</li>
<li>#165 <code>onMissingView()</code> correctly called when view is missing</li>
<li>#163 trace code no longer fails if session scope is disabled</li>
<li>#160 <code>buildURL()</code> sanity checks <code>queryString</code> as struct</li>
<p>Additional changes:</p>
<li>fixed error message for service() missing action</li>
<li>framework initialization logic is more robust</li>
<li>improve example that uses DI/1 to avoid confusion over what to manage</li>
<li>improve consistency of framework injection (of itself)</li>
<li>layout trace shows correct path</li>
]]></content>
    <title type="html"><![CDATA[FW/1 the Year Ahead]]></title>
    <link href="http://framework-one.github.io/blog/2013/11/02/fw1-the-year-ahead/"/>
    <updated>2013-11-02T23:42:41-07:00</updated>
    <id>http://framework-one.github.io/blog/2013/11/02/fw1-the-year-ahead</id>
    <content type="html"><![CDATA[<p>With FW/1 Version 2.2 just around the corner &ndash; after a long time in incubation &ndash; and FW/1 itself being almost four and a half years old, it&rsquo;s a good time to look ahead at what&rsquo;s in store.<!-- more --></p>
<p>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 &ndash; start/end-item &ndash; to wrap the automatic call to the service layer.</p>
<p>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&rsquo;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&#8217; controller calls are also queued (although that&rsquo;s mostly invisible to users).</p>
<p>In version 2.5, scheduled for early January 2014, FW/1 will begin the move away from queuing services by deprecating the <code>service()</code> 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 <code>service()</code> 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!</p>
<p>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 <code>containsBean()</code> and <code>getBean()</code> API such as ColdSpring (WireBox uses a slightly different API but I plan to provide an adapter for it in 2.5).</p>
<p>Also as part of 3.0, the framework CFC itself will be renamed and the <code>/org/corfield</code> structure removed. The default path will be <code>/framework/one.cfc</code> so your <code>Application.cfc</code> will have <code>extends="framework.one"</code> by default. In 2.5, DI/1 will have adopted this pattern as <code>/framework/ioc.cfc</code>, but since 2.5 will still be backward compatible with 2.2 (after you&rsquo;ve added the compatibility setting in <code>Application.cfc</code>), I don&rsquo;t want to force renaming or reorganizing on users until 3.0.</p>
<p>Finally, as part of 3.0, the entire repository will be restructured to better reflect what is considered &ldquo;best practices&rdquo; 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 &ldquo;best practice&rdquo; out-of-the-box experience.</p>
<p>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.</p>
]]></content>
    <title type="html"><![CDATA[Where Can I Download Old Versions of FW/1?]]></title>
    <link href="http://framework-one.github.io/blog/2013/05/07/where-can-i-download-old-versions-of-fw1/"/>
    <updated>2013-05-07T14:18:12-07:00</updated>
    <id>http://framework-one.github.io/blog/2013/05/07/where-can-i-download-old-versions-of-fw1</id>
    <content type="html"><![CDATA[<p>I&rsquo;ve been asked this several times recently so I figured it was worth a blog post. First of, why would anyone want older versions of the framework? Well, if they&rsquo;re running on Adobe ColdFusion 9.0.0 or earlier, they can&rsquo;t use the 2.x release stream: they&rsquo;re stuck on 1.x. Also, if they&rsquo;re currently using an old version and don&rsquo;t want a major upgrade, they might want a minor upgrade for a bug fix.<!-- more --></p>
<p>Okay, so why haven&rsquo;t I blogged about this before? Truth be told, I thought it was &ldquo;obvious&rdquo; how to find specific legacy releases on any Github project. Apparently, it is not obvious for everyone so it is worth blogging about. Every properly managed project on Github tags every official release so that all past releases can be found on the &lsquo;tags&rsquo; page. You can see <a href="https://github.com/framework-one/fw1/tags">FW/1&rsquo;s &lsquo;tags&rsquo; page</a> where you can find every release since 1.0. Unfortunately, my choice of naming for tags has not always been consistent and I forgot the &lsquo;v&rsquo; prefix for a while around the release of 2.0. Oops. Unfortunately the typical naming convention for prereleases tends to sort them above their gold release versions &ndash; see <a href="https://github.com/clojure/core.logic/tags">Clojure&rsquo;s core.logic library&rsquo;s tags</a> for a more striking example. At least Github provides an easy mechanism for provided tagged archive releases.</p>
<p>It&rsquo;s probably worth pointing out that downloading FW/1 directly from the <a href="http://fw1.riaforge.org/">FW/1 RIAForge project page</a> will give you the latest stable release which is currently 2.1.1. That&rsquo;s because it downloads a ZIP file of the &ldquo;master&rdquo; branch from the Github site. All development is performed on the &ldquo;develop&rdquo; branch. The only time the RIAForge site will slip you something different is when a new release is in the Release Candidate stage and I update the RIAForge page to download a ZIP file of the &ldquo;develop&rdquo; branch &ndash; and I update the page to clearly state that! &ndash; and this is to increase adoption of the new release and help flush out any remaining bugs that haven&rsquo;t been caught during the alpha and beta testing phases.</p>
]]></content>
Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

atom.xml

Latest commit

History

atom.xml

File metadata and controls
