Prep for 4.0 release

seancorfield · seancorfield · commit 804d852b292a · 2016-09-16T20:24:18.000-07:00
diff --git a/source/documentation/4.0/cfml-and-clojure.markdown b/source/documentation/4.0/cfml-and-clojure.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "Using Clojure with CFML"
-date: 2016-09-14 15:00
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 # Clojure and CFML Sitting in a tree
 {:.no_toc}
 
diff --git a/source/documentation/4.0/changes.markdown b/source/documentation/4.0/changes.markdown
@@ -6,8 +6,6 @@ comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 The following changes are part of FW/1 4.0, DI/1 1.2.0, and cfmljure 1.1.0.
 
 Summary
diff --git a/source/documentation/4.0/developing-applications.markdown b/source/documentation/4.0/developing-applications.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "Developing Applications with FW/1"
-date: 2016-07-12 10:20
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 FW/1 is intended to allow you to quickly build applications with the minimum of overhead and interference from the framework itself. The convention-based approach means that you can quickly put together an outline of your site or application merely by creating folders and files in the `views` folder. As you are ready to start adding business logic to the application, you can add controllers and/or services and domain objects as needed to implement the validation and data processing.
 
 * Table of Contents
diff --git a/source/documentation/4.0/index.markdown b/source/documentation/4.0/index.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "Getting Started with FW/1"
-date: 2016-05-27 19:00
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 FW/1 was created in July 2009 as a reaction against complexity and bloat in other frameworks in the CFML community. FW/1 itself is a single file, and provides a simple, convention-based approach to MVC (Model-View-Controller) applications, as well as REST APIs. Whilst it has become more sophisticated over time, it has remained a single file, focused on getting out of your way and providing the intuitive plumbing you need. For historical background, you can read the [introductory blog post](http://framework-one.github.io/blog/2009/07/19/introducing-framework-one/) from July 2009.
 
 As of release 3.1, FW/1 also includes DI/1 - a simple, convention-based Dependency Injection framework - and AOP/1 - a simple, convention-based Aspect-Oriented Programming framework. As of release 3.5, FW/1 lets you mix'n'match CFML and Clojure code. If those phrases don't mean anything to you, don't worry, you won't need to know anything about them to get started. For a full list of changes in this release, see the [Change Log](changes.html).
diff --git a/source/documentation/4.0/reference-manual.markdown b/source/documentation/4.0/reference-manual.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "FW/1 Reference Manual"
-date: 2016-05-20 20:30
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 This page provides a description of all the APIs and components involved in a FW/1 application. Please also read the [Roadmap](roadmap.html) to see how things may change in the future.
 
 * TOC
@@ -529,7 +527,7 @@ Override this in your `Application.cfc` to provide request-specific initializati
 
 ## public void function setupResponse( struct rc )
 
-Override this in your `Application.cfc` to provide request-specific finalization. This is called after all views and layouts have been rendered or immediately before a redirect. You do not need to call `super.setupResponse()`. 
+Override this in your `Application.cfc` to provide request-specific finalization. This is called after all views and layouts have been rendered or immediately before a redirect. You do not need to call `super.setupResponse()`.
 
 ## public void function setupSession()
 
@@ -545,7 +543,7 @@ This is called when the framework trace is about to be rendered at the end of a
 
 ## public void function setupView( struct rc )
 
-Override this in your `Application.cfc` to provide pre-rendering logic, e.g., putting globally available data into the request context so it is available to all views. You do not need to call `super.setupView()`. 
+Override this in your `Application.cfc` to provide pre-rendering logic, e.g., putting globally available data into the request context so it is available to all views. You do not need to call `super.setupView()`.
 
 ## public void function setView( string action )
 
diff --git a/source/documentation/4.0/roadmap.markdown b/source/documentation/4.0/roadmap.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "FW/1 Roadmap"
-date: 2016-01-05 23:00
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 Whilst you can read the [FW/1 issues list](https://github.com/framework-one/fw1/issues) to see what's on the cards for future releases, several people have asked that I document things at a higher level so they can get a better sense of what's coming.
 
 5.x Lifecycle Restructuring
diff --git a/source/documentation/4.0/using-aop-one.markdown b/source/documentation/4.0/using-aop-one.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "Using AOP/1"
-date: 2015-10-27 10:00
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 AOP/1 is a simple Aspect Oriented Programming extension for [DI/1 (a.k.a Inject One)](using-di-one.html) which allows you to define interceptors for your beans.
 
 These interceptors can run code before or after a method is called on a bean without the need for you to alter the code in your bean.  This allows you to create generic services (such as a logger service) that is coded and configured to operate completely separate from your other services and beans.  What this means is you no longer need to mix unrelated service code together by using dedicated interceptors.
@@ -26,12 +24,12 @@ Create an instance of the AOP/1 extended DI/1 bean factory and specify the folde
 So far nothing difficult since this is what we would typically see from [DI/1](using-di-one.html).  Now, if we want to intercept method calls to an object, we need to declare the interceptors and the objects that should be intercepted.
 
     var beanFactory = new framework.aop("/model");
-    
+
     beanFactory.intercept("pdfService", "beforeInterceptor");
     beanFactory.intercept("pdfService", "afterInterceptor", "createDocument");
-    
+
     var ps = beanFactory.getBean("pdfService");
-    
+
     var document = ps.createDocument("http://seancorfield.github.io");
     var pages = ps.splitPages(document);
 
@@ -57,7 +55,7 @@ Before interceptors will intercept method calls _before_ they are executed.  The
             arguments.args.input = "before" & arguments.args.input;
         }
     }
-    
+
 Because the interceptor is like any other bean handled by DI/1, dependencies can be intjected into the interceptor and used by the interceptor.
 
     component {
@@ -185,5 +183,3 @@ Stacks are executed in the following order.
 * **onError**
 
 All the stacks will only execute if there is an interceptor of their type present.  If the stack is emtpy, nothing is executed.  The **onError** stack only executes if there is an error in the execution of the other stacks.  The **before** and **after** stacks execute like a queue and will execute from start to finish regardless of changes to the arguments or result, skipping any interceptors that do not match the currently intercepted bean method.  The **around** stack executes more like a chain.  The chain execution can be stopped by not calling the `proceed()` method.
-
-
diff --git a/source/documentation/4.0/using-di-one.markdown b/source/documentation/4.0/using-di-one.markdown
@@ -1,14 +1,12 @@
 ---
 layout: page
 title: "Using DI/1"
-date: 2016-04-07 11:30
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
-DI/1 - a.k.a Inject One - is a simple, convention-based Dependency Injection framework. 
+DI/1 - a.k.a Inject One - is a simple, convention-based Dependency Injection framework.
 
 DI/1 searches specified directories for CFCs and treats them as singletons or non-singletons (transients) based on naming conventions for the CFCs themselves, or the folders in which they are found. You can override the conventions by configuration if needed.
 
@@ -57,18 +55,18 @@ If a CFC has a constructor (a method called `init()`), DI/1 will use the argumen
 
     // usermanager - managers/user.cfc or usermanager.cfc
     component accessors=true {
-    
+
         property roleService; // autowire services/role.cfc
-        
+
         function setLoggingService( loggingService ) { // autorwire services/logging.cfc
             variables.logger = loggingService.getLogger( "user" );
         }
-        
+
         function init( userdao ) { // autowire daos/user.cfc
             variables.userdao = userdao;
             return this;
         }
-        
+
     }
 
 When you get this `usermanager` bean from DI/1 -- either by calling `getBean( "usermanager" )` directly or autowired into another bean via `property usermanager;` (or a setter or constructor argument), it will already have `roleService`, `loggingService`, and `userDAO` autowired into it.
diff --git a/source/documentation/4.0/using-subsystems.markdown b/source/documentation/4.0/using-subsystems.markdown
@@ -1,13 +1,11 @@
 ---
 layout: page
 title: "Using Subsystems in FW/1"
-date: 2015-10-27 10:00
+date: 2016-09-16 20:00
 comments: false
 sharing: false
 footer: true
 ---
-_This is documentation for the upcoming 4.0 release. For the current release, see [this documentation](/documentation/)._
-
 Subsystems give you a way of modularizing your FW/1 application as it grows. They also provide a way to incorporate other FW/1 applications directly into an existing one. Subsystems can be used to create modules that have no dependencies on the parent application or you can use subsystems to group common functionality together.
 
 * TOC
@@ -107,7 +105,7 @@ Legacy subsystems do not have the `subsystems/` prefix.
 
 Views
 ---
-Subsystem views are located in `subsystems/module/views` (e.g., `subsystems/admin/views/login/default.cfm` and `subsystems/home/views/main/error.cfm`). 
+Subsystem views are located in `subsystems/module/views` (e.g., `subsystems/admin/views/login/default.cfm` and `subsystems/home/views/main/error.cfm`).
 
 Legacy subsystems do not have the `subsystems/` prefix.
 
@@ -128,7 +126,7 @@ In addition to your top-level bean factory, you can have subsystem-specific bean
 
 The following bean factory methods are available for subsystems:
 
-* `setSubsystemBeanFactory( subsystem, beanFactory )` - sets up a subsystem specific bean factory 
+* `setSubsystemBeanFactory( subsystem, beanFactory )` - sets up a subsystem specific bean factory
 * `hasSubsystemBeanFactory( subsystem )` - returns `true` if a subsystem specific bean factory exists for the named subsystem
 * `getBeanFactory()` - returns the bean factory for the current subsystem. Alternately, it can be used to retrieve the bean factory for another subsystem by passing the name of the subsystem (e.g., `getBeanFactory( subsystem )` ).
 * `getDefaultBeanFactory()` - returns the default bean factory that was passed to `setBeanFactory()` (at the top-level)
