GitBook: [master] 36 pages modified

Author: lmajano

digging-deeper/coldbox-proxy/the-base-proxy-object.md

@@ -3,7 +3,7 @@
 Here are some common methods of our ColdBox proxy object. However, we encourage you to see the [API docs](http://apidocs.ortussolutions.com/coldbox/current) for that latest and greatest.
 
 | Method | Description |
-| --- | --- |
+| :--- | :--- |
 | announceInterception\(state, data\) | Processes a remote interception. |
 | getCacheBox\(\) | Get a reference to [CacheBox](http://wiki.coldbox.org/wiki/CacheBox.cfm) |
 | getCache\(cacheName='default'\) | Get a reference to a named cache provider |

digging-deeper/flash-ram/creating-your-own-flash-scope.md

@@ -8,7 +8,7 @@ The ColdBox Flash capabilities are very flexible and you can easily create your
 ## Implementable Methods
 
 | Method | ReturnType | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | clearFlash\(\) | void | Will destroy or clear the entire flash storage structure. |
 | saveFlash\(\) | void | Will be called before relocations or on demand in order to flash the storage. This method usually talks to the getScope\(\) method to retrieve the temporary flash variables and then serialize and persist. |
 | flashExists\(\) | boolean | Checks if the flash storage is available and has data in it. |

digging-deeper/flash-ram/flash-storage.md

@@ -19,7 +19,7 @@ flash = {
 Below is a nice chart of all the keys in this configuration structure so you can alter behavior of the Flash RAM objects:
 
 | Key | Type | Required | Default | Description |
-| --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- |
 | scope | string or instantiation path | false | _session_ | Determines what scope to use for Flash RAM. The available aliases are: session, client, cluster, cache or a custom instantiation path |
 | properties | struct | false | {} | Properties that can be used inside the constructor of any Flash RAM implementation |
 | inflateToRC | boolean | false | true | Whatever variables you put into the Flash RAM, they will also be inflated or copied into the request collection for you automatically. |
@@ -32,7 +32,7 @@ Below is a nice chart of all the keys in this configuration structure so you can
 The included flash implementations for ColdBox are:
 
 | Name | Class | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | Session | coldbox.system.web.flash.SessionFlash | Persists variables in session scope |
 | Cluster | coldbox.system.web.flash.ClusterFlash | Persists variables in cluster scope via Railo only |
 | Client | coldbox.system.web.flash.ClientFlash | Persists variables in client scope |

digging-deeper/interceptors/core-interception-points/application-life-cycle-events.md

@@ -1,7 +1,7 @@
 # Application Life Cycle Events
 
 | Interception Point | Intercept Structure | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | afterConfigurationLoad | --- | This occurs after the framework loads and your applications' configuration file is read and loaded. An important note here is that your application aspects have not been configured yet: bug reports, ioc plugin, validation, logging, and internationalization. |
 | afterAspectsLoad | --- | \(DEPRECATED.  Use modules instead.\) This occurs after the configuration loads and the aspects have been configured. This is a great way to intercept on application start. |
 | preReinit | --- | This occurs every time the framework is re-initialized |

digging-deeper/interceptors/core-interception-points/layout-view-events.md

@@ -1,7 +1,7 @@
 # Layout-View Events
 
 | Interception Point | Intercept Structure | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | preLayout | --- | This occurs before any rendering or layout is executed |
 | preRender | {renderedContent} | This occurs after the layout+view is rendered and this event receives the produced content |
 | postRender | --- | This occurs after the content has been rendered to the buffer output |

digging-deeper/interceptors/core-interception-points/module-events.md

@@ -1,7 +1,7 @@
 # Module Events
 
 | Interception Point | Intercept Structure | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | preModuleLoad | {moduleLocation, moduleName} | This occurs before any module is loaded in the system |
 | postModuleLoad | {moduleLocation, moduleName, moduleConfig} | This occurs after a module has been loaded in the system |
 | preModuleUnload | {moduleName} | This occurs before a module is unloaded from the system |

digging-deeper/interceptors/core-interception-points/object-creating-events.md

@@ -1,7 +1,7 @@
 # Object Creating Events
 
 | Interception Point | Intercept Structure | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | afterHandlerCreation | handlerPath - The handler path | This occurs whenever a handler is created |
 | afterInstanceCreation | mapping - The object mapping | This occurs whenever a [wirebox](http://wiki.coldbox.org/wiki/Wirebox.cfm) object is created |
 

digging-deeper/interceptors/interceptor-asynchronicity/README.md

@@ -9,7 +9,7 @@ any announceInterception(state, interceptData, async, asyncAll, asyncAllJoin, as
 The asynchronous arguments are listed in the table below:
 
 | Argument | Type | Required | Default Value | Description |
-| --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- |
 | async | boolean | false | false | Threads the interception call so the entire execution chain is ran in a separate thread. Extra arguments that can be used: asyncPriority. |
 | asyncAll | boolean | false | false | Mutually exclusive with the async argument. If true, this will execute the interception point but multi-thread each of the CFCs that are listening to the interception point. So if 3 CFCs are listening, then 3 separate threads will be created for each CFC call. By default, the calling thread will wait for all 3 separate threads to finalize in order to continue with the execution. Extra arguments that can be used: _asyncAllJoin_, _asyncTimeout_, _asyncPriority_. |
 | asyncAllJoin | boolean | false | true | This flag is used only when combined with the asyncAll argument. If true \(default\), the calling thread will wait for all intercepted CFC calls to execute. If false, then the calling thread will not join the multi-threaded interception and continue immediate execution while the CFC's continue to execute in the background. |

digging-deeper/interceptors/interceptor-asynchronicity/asynchronous-annotations.md

@@ -3,7 +3,7 @@
 We have also extended the interceptor registration process so you can annotate interception points to denote threading. You will do so with the following two annotations:
 
 | Argument | Type | Required | Default Value | Description |
-| --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- |
 | `async` | none | false | false | If the annotation exists, then ColdBox will execute the interception point in a separate thread only if not in a thread already. |
 | `asyncPriority` | string : _low,normal,high_ | false | _normal_ | The thread priority that will be sent to each cfthread call that is made by the system. |
 

for-newbies/60-minute-quick-start/my-first-coldbox-application.md

@@ -74,7 +74,7 @@ That's it, you have just created your first application. Hooray, onward!
 ColdBox is a conventions based framework. The location of files and functions matter. Since we scaffolded our first application, let's write down in a table below with the different conventions that exist in ColdBox.
 
 | **File/Folder Convention** | **Mandatory** | **Description** |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| :--- | :--- | :--- |
 | `config/Coldbox.cfc` | false | The application configuration file |
 | `config/Router.cfc` | false | The application URL router |
 | `handlers` | false | Event Handlers \(controllers\) |

getting-started/configuration/bootstrapper-application.cfc.md

@@ -99,7 +99,7 @@ component extends="coldbox.system.Bootstrap"{
 You can set some variables in the `Application.cfc` that can alter Bootstrapping conditions:
 
 | **Variable** | **Default** | **Description** |
-| --- | --- |
+| :--- | :--- | :--- |
 | `COLDBOX_APP_ROOT_PATH` | App Directory | Automatically set for you. This path tells the framework what is the base root location of your application and where it should start looking for all the agreed upon conventions. You usualy will never change this, but you can. |
 | `COLDBOX_APP_MAPPING` | `/` | The application mapping is ESSENTIAL when dealing with Flex or Remote \(SOAP\) applications. This is the location of the application from the root of the web root. So if your app is at the root, leave this setting blank. If your application is embedded in a sub-folder like MyApp, then this setting will be auto-calculated to `/MyApp`. |
 | `COLDBOX_CONFIG_FILE` | `config/ColdBox.cfc` | The absolute or relative path to the configuration CFC file to load. This bypasses the conventions and uses the configuration file of your choice. |

getting-started/configuration/coldbox.cfc/configuration-directives/README.md

@@ -31,7 +31,7 @@ Please note that the only required directive is `coldbox.appName`.
 Inside of this configuration method you will place several core and third-party configuration structures that can alter your application settings and behavior. Below are the core directives you can define:
 
 | Directive | Type | Description |
-| --- | --- |
+| :--- | :--- | :--- |
 | [cachebox](cachebox.md) | struct | An optional structure used to configure CacheBox. If not setup the framework will use its default configuration found in `/coldbox/system/web/config/CacheBox.cfc` |
 | [coldbox](coldbox.md) | struct | The main coldbox directives structure that holds all the coldbox settings. |
 | [conventions](conventions.md) | struct | A structure where you will configure the application convention names |

getting-started/configuration/coldbox.cfc/system-settings-java-properties-and-environment-variables.md

@@ -3,7 +3,7 @@
 ColdBox makes it easy to access the configuration stored in your Java system properties and your server's environment variables, even if you don't know which one it is in! Three methods are provided for your convenience:
 
 | Name | Arguments | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | `getSystemSetting` | `( key, defaultValue )` | Looks for `key` in properties first, env second. Returns the `defaultValue` if neither exist. |
 | `getSystemProperty` | `( key, defaultValue )` | Returns the Java System property for `key`. Returns the `defaultValue` if it does not exist. |
 | `getEnv` | `( key, defaultValue )` | Returns the server environment variable for `key`. Returns the `defaultValue` if it does not exist. |

getting-started/conventions.md

@@ -16,7 +16,7 @@ The core conventions delineate the contract between ColdBox and you for file/dir
 ## Execution Conventions
 
 | **Convention** | **Default Value** | **Description** |
-| --- | --- | --- | --- |
+| :--- | :--- | :--- |
 | Default Event | `main.index` | The default event to execute when no event is specified |
 | Default Action | `index()` | The default action to execute in an event handler controller if none is specified |
 | Default Layout | `layouts/Main.cfm` | The default system layout to use |

hmvc/modules/layout-and-view-renderings/README.md

@@ -3,7 +3,7 @@
 The ColdBox rendering engine has been adapted to support module renderings and also to support multiple discovery algorithms when rendering module layouts and views. When you declare a module you can declare two of its public properties to determine how rendering overrides occur. These properties are:
 
 | Property | Type | Required | Default | Description |
-| --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- |
 | viewParentLookup | boolean | false | true | If true, coldbox checks for views in the parent overrides first, then in the module. If false, coldbox checks for views in the module first, then the parent. |
 | layoutParentLookup | boolean | false | true | If true, coldbox checks for layouts in the parent overrides first, then in the module. If false, coldbox checks for layouts in the module first, then the parent. |
 

hmvc/modules/moduleconfig/public-module-properties-directives.md

@@ -3,7 +3,7 @@
 First of all, we must define some public properties that can easily identify or provide directives for the module:
 
 | Property | Type | Required | Default | Description |
-| --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- |
 | title | string | false | --- | The title of the module |
 | author | string | false | --- | The author of the module |
 | webURL | string | false | --- | The web URL associated with this module. Maybe for documentation, blog, links, etc. |

hmvc/modules/moduleconfig/the-configure-method.md

@@ -3,7 +3,7 @@
 Once the public properties are set, we are now ready to configure our module. You will do this by creating a simple method called `configure()` and adding variables to the following configuration structures:
 
 | Property | Type | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | parentSettings | struct | Settings that will be appended and override the host application settings |
 | settings | struct | Custom module settings that will only be available to the module. If `parseParentSettings` is set to true \(default\), then settings from `config/Coldbox.cfc` for this module will be merged with these settings. \(Think of these as default settings in that case.\) Please see the retrieving settings section |
 | conventions | struct | A structure that explains the layout of the handlers, plugins, layouts and views of this module. |

hmvc/modules/moduleconfig/the-decorated-variables.md

@@ -5,7 +5,7 @@
 At runtime, the configuration object will be created by ColdBox and decorated with the following private properties \(available in the `variables` scope\):
 
 | Property | Description |
-| --- | --- |
+| :--- | :--- |
 | appMapping | The `appMapping` setting of the current host application |
 | binder | The WireBox configuration binder object |
 | cachebox | A reference to CacheBox |

intro/introduction/upgrading-to-coldbox-4.md

@@ -197,7 +197,7 @@ box install cborm
 This module brings you all the ORM virtual services that are in ColdBox 3.x and replaces the `ORMService` Plugin, but note that the component paths have been updated. Instead of starting with `coldbox.system` they start with `cborm`.
 
 | Old Path | New Path |
-| --- | --- |
+| :--- | :--- |
 | coldbox.system.orm.hibernate.VirtualEntityService | cborm.models.VirtualEntityService |
 | coldbox.system.orm.hibernate.ActiveEntity | cborm.models.ActiveEntity |
 | coldbox.system.orm.hibernate.BaseORMService | cborm.models.BaseORMService |
@@ -281,7 +281,7 @@ This module replaces the Security interceptor. The interceptor still exists, but
 Some of these were covered above, but for completeness, here is a comprehensive list of the WireBox DSL Namespaces that are removed.
 
 | **Removed DSL** | **Replacement DSL** |
-| --- | --- |
+| :--- | :--- |
 | **ocm** | **cachebox:default** |
 | **ocm:{keyName}** | **cachebox:default:{keyName}** |
 | **coldbox:plugin:{pluginName}** | **model:{modelName@module}** |

intro/introduction/whats-new-with-4.0.0/README.md

@@ -353,7 +353,7 @@ We have altered the module services to now allow you to nest modules within modu
 The ''ModuleConfig.cfc'' has been updated with several new properties:
 
 | Setting | Type | Required | Default | Description |
-| --- | --- | --- | --- | --- |
+| :--- | :--- | :--- | :--- | :--- |
 | **activate** | boolean | false | true | You can tell ColdBox to register the module but NOT to activate it. By default, all modules activate. |
 | **aliases** | array | false | \[\] | An array of names that can be used to execute the module instead of only the module folder name |
 | **autoMapModels** | boolean | false | true | Will automatically map all model objects under the **models** folder in WireBox using `@modulename` as part of the alias. |

the-basics/event-handlers/event-caching.md

@@ -27,7 +27,7 @@ To enable event caching, you will need to set a setting in your `ColdBox.cfc` ca
 The way to set up an event for caching is on the function declaration with the following annotations:
 
 | **Annotation** | **Type** | **Description** |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | `cache` | boolean | A true or false will let the framework know whether to cache this event or not. The default is FALSE. So setting to false makes no sense |
 | `cachetimeout` | numeric | The timeout of the event's output in minutes. This is an optional attribute and if it is not used, the framework defaults to the default object timeout in the cache settings. You can place a 0 in order to tell the framework to cache the event's output for the entire application timeout controlled by coldfusion, NOT GOOD. Always set a decent timeout for content. |
 | `cacheLastAccesstimeout` | numeric | The last access timeout of the event's output in minutes. This is an optional attribute and if it is not used, the framework defaults to the default last access object timeout in the cache settings. This tells the framework that if the object has not been accessed in X amount of minutes, then purge it. |

the-basics/event-handlers/interception-methods/README.md

@@ -7,7 +7,7 @@ There are several simple implicit [AOP](http://en.wikipedia.org/wiki/Aspect-orie
 This is great for intercepting calls, pre/post processing, localized security, logging, RESTful conventions, and much more. Yes, you got that right, [Aspect Oriented Programming](http://en.wikipedia.org/wiki/Aspect-oriented_programming) just for you and without all the complicated setup involved! If you declared them, the framework will execute them.
 
 | **Interceptor Method** | **Description** |
-| --- | --- |
+| :--- | :--- |
 | `preHandler()` | Executes **before** any requested action \(In the same handler CFC\) |
 | `pre{action}()` | Executes **before** the `{action}` requested ONLY |
 | `postHandler()` | Executes **after** any requested action \(In the same handler CFC\) |

the-basics/layouts-and-views/README.md

@@ -25,7 +25,7 @@ Let's do a recap of our conventions for layouts and view locations:
 It is imperative to know who does the rendering in ColdBox and that is the **Renderer** class that you can see from our diagram above. As you can tell from the diagram, it includes your layouts and/or views into itself in order to render out content. So by this association and inheritance all layouts and views have some variables and methods at their disposal since they get absorbed into the object. You can visit the [API docs](http://apidocs.ortussolutions.com/coldbox/current) to learn about all the Renderer methods. All of the following property members exist in all layouts and views rendered by the **Renderer**:
 
 | **Property** | **Description** |
-| --- | --- |
+| :--- | :--- |
 | `event` | A reference to the Request Context object |
 | `rc` | A reference to the request collection inside of the request context \(For convenience\) |
 | `prc` | A reference to the private request collection inside of the request context \(For convenience\) |

the-basics/layouts-and-views/layouts/layout-events.md

@@ -3,7 +3,7 @@
 All rendered layouts have associated events that are announced whenever the layout is rendered via ColdBox Interceptors. These are great ways for you to be able to intercept when layouts are rendered and transform them, append to them, or even remove content from them in a completely decoupled approach. The way to listen for events in ColdBox is to write Interceptors, which are essential simple CFC's that by convention have a method that is the same name as the event they would like to listen to. Each event has the capability to receive a structure of information wich you can alter, append or remove from. Once you write these Interceptors you can either register them in your Configuration File or programmatically.
 
 | Event | Data | Description |
-| --- | --- | --- |
+| :--- | :--- | :--- |
 | `preLayoutRender` | layout - The name of the layout to render | Executed before any layout is rendered |
 | `postLayoutRender` | All of the data above plus:  | Executed after a layout was rendered |