Skip to content

Commit 97b8636

Browse files
lmajanolmajano
committed
fixed asset paths now to globa /.gitbook/assets
1 parent 1dc7fa0 commit 97b8636

File tree

30 files changed

+43
-43
lines changed

30 files changed

+43
-43
lines changed

‎architecture-concepts/how-coldbox-works.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ ColdBox is loaded by the `Application.cfc` and makes use of the Front Controller
1414

1515
The incoming URL, FORM, and REMOTE variables are merged into a single structure that we call the request collection and, since we love objects, that collection is stored in an object called Request Context. We also create a secondary collection called the private request collection that cannot be affected by the outside world as nothing is merged into it. You can use it for private request variables and the like.
1616

17-
![](/.gitbook/assets/RequestCollectionDataBus.jpg)
17+
![](/.gitbook/assets/requestcollectiondatabus.jpg)
1818

1919
The request context object has tons of methods to help you in setting and getting variables from one MVC layer to another, to getting request metadata, rendering RESTful content, setting HTTP headers, and more. It is your information super highway for specific requests. Remember that the API Docs are your best friend!
2020

‎architecture-concepts/testing-concepts/bugs-cost-money.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Bugs Cost Money
22

3-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/BugsCostMoney.png)
3+
![](/.gitbook/assets/BugsCostMoney.png)
44

55
> Kaner, Cem; James Bach, Bret Pettichord \(2001\). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley. p. 4. ISBN 0-471-08112-4.
66

‎architecture-concepts/what-is-coldbox.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# What is ColdBox
22

3-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ColdBoxLogo2015_300.png)
3+
![](/.gitbook/assets/ColdBoxLogo2015_300.png)
44

55
ColdBox is a conventions-based MVC framework for ColdFusion \(CFML\). It is fast, scalable, and runs on CFML engines such as Adobe ColdFusion and the open source CFML engine [Lucee](http://www.lucee.org), for a completely free and open source development stack. ColdBox itself is Professional Open Source Software, backed by [Ortus Solutions](http://www.ortussolutions.com) which provides support, training, architecture, consulting and commercial additions.
66

@@ -10,19 +10,19 @@ Here’s a look at some of the core components of the ColdBox platform. Each of
1010

1111
## WireBox
1212

13-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/WireBox.png)
13+
![](/.gitbook/assets/WireBox.png)
1414

1515
Managing your domain objects has never been easier with this Dependency Injection and Inversion of Control \(IOC\) framework. WireBox supports all forms of injection as well as maintaining persistence for your domain objects. WireBox can also interface and provide Java classes, web services, and aspects of the ColdBox framework itself. WireBox also has built-in Aspect Oriented Programming \(AOP\) support; you’ll never need another Dependency Injection engine again.
1616

1717
## LogBox
1818

19-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/LogBox.png)
19+
![](/.gitbook/assets/LogBox.png)
2020

2121
This is a highly-configurable logging library which can be set up to relay messages of different types from any portion of your application to any number of predefined logging appenders.
2222

2323
## CacheBox
2424

25-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/CacheBox.png)
25+
![](/.gitbook/assets/CacheBox.png)
2626

2727
A highly-versatile caching aggregator and enterprise cache that allows for multiple named caching stores as well as granular control over cache behaviors and eviction policies. CacheBox can interface out of the box with Ehcache, Adobe ColdFusion cache, and any Lucee cache.
2828

‎digging-deeper/coldbox-proxy/README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# ColdBox Proxy
22

3-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ColdBoxProxy.png)
3+
![](/.gitbook/assets/ColdBoxProxy.png)
44

55
The ColdBox proxy enables remote applications or technologies like Flex, AIR, SOAP WebServices, Event Gateways, ColdFusion RESTful Webservices to communicate with ColdBox and provide an event driven model framework for those applications or for it to act as an enhanced service layer.
66

‎digging-deeper/flash-ram/README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -2,11 +2,11 @@
22

33
The purpose of the Flash RAM is to allow variables to be persisted seamlessly from one request and be picked up in a subsequent request\(s\) by the same user. This allows you to hide implementation variables and create web flows or conversations in your ColdBox applications. So why not just use session or client variables? Well, most developers forget to clean them up and sometimes they just end up overtaking huge amounts of RAM and no clean cut definition is found for them. With Flash RAM, you have the facility already provided to you in an abstract and encapsulated format. This way, if you need to change your flows storage scope from session to client scope, the change is seamless and painless.
44

5-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/FlashRAMSequence.jpg)
5+
![](/.gitbook/assets/FlashRAMSequence.jpg)
66

77
Every handler, plugin, interceptor, layout and view has a flash object in their variables scope already configured for usage. The entire flash RAM capabilities are encapsulated in a flash object that you can use in your entire ColdBox code. Not only that, but the ColdBox Flash object is based on an interface and you can build your own Flash RAM implementations very easily. It is extremely flexible to work on a concept of a Flash RAM object than on a storage scope directly. So future changes are easily done at the configuration level.
88

9-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ColdBoxMajorClasses.jpg)
9+
![](/.gitbook/assets/ColdBoxMajorClasses.jpg)
1010

1111
Our Flash Scope also can help you maintain flows or conversations between requests by using the `discard()` and `keep()` methods. This will continue to expand in our 3.X releases as we build our own conversations DSL to define programmatically wizard like or complex web conversations. Also, the ColdBox Flash RAM has the capability to not only maintain this persistence scope but it also allows you to seamlessly re-inflate these variables into the request collection or private request collection, both or none at all.
1212

‎digging-deeper/interceptors/README.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
Interceptors are CFC listeners that react on incoming events. Events can be announced by the core framework or be custom events from your application. These interceptors can also be stacked to form interceptor chains that can be executed implicitly for you. This is a powerful feature that can help developers and framework contributors share and interact with their work. \(Read more on [Intercepting Filters](http://www.corej2eepatterns.com/Patterns2ndEd/InterceptingFilter.htm)\)
44

5-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/InterceptorChain.gif)
5+
![](/.gitbook/assets/InterceptorChain.gif)
66

77
## Event Driven Programming
88

@@ -20,7 +20,7 @@ if( userCreated ){
2020
}
2121
```
2222

23-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/eventdriven.jpg)
23+
![](/.gitbook/assets/eventdriven.jpg)
2424

2525
If you are familiar with design patterns, custom interceptors can give you an implementation of observer/observable listener objects, much like any event-driven system can provide you. In a nutshell, an observer is an object that is registered to listen for certain types of events, let's say as an example `onError` is a custom interception point and we create a CFC that has this `onError` method. Whenever in your application you announce or broadcast that an event of type onError occurred, this CFC will be called by the ColdBox interceptor service.
2626

‎digging-deeper/interceptors/how-do-they-work/README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
Interceptors are CFCs that extend the ColdBox Interceptor class \(`coldbox.system.Interceptor`\), implement a configuration method called `configure()`, and then contain methods for the events it will listen for. All interceptors are treated as **singletons** in your application, so make sure they are thread safe and var scoped.
44

5-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ColdBoxMajorClasses.jpg)
5+
![](/.gitbook/assets/ColdBoxMajorClasses.jpg)
66

77
```text
88
/**

‎digging-deeper/recipes/debugging-coldbox-apps.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -8,5 +8,5 @@ install cbdebugger --saveDev
88

99
Remember that this module is for development so use the `--saveDev` flag. This will install the ColdBox Debugger module for you, which will attach a debugger to the end of the request and give you lots of flexibility. Please read the instructions here in order to spice it up as you see fit: [https://github.com/ColdBox/cbox-debugger](https://github.com/ColdBox/cbox-debugger)
1010

11-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/cachemonitor.jpg)
11+
![](/.gitbook/assets/cachemonitor.jpg)
1212

‎hmvc/modules/README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Modules
22

3-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/Modules.png)
3+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/Modules.png)
44

55
ColdBox Modules are self-contained subsets of a ColdBox application that can be dropped in to any ColdBox application and become alive as part of the host application. They will bring re-usability and extensibility to any ColdBox application, as now you can break them down further into a collection of modules instead of monolithic approaches. CommandBox will also help you manage, install, track and uninstall modules as part of your development workflow.
66

‎hmvc/modules/layout-and-view-renderings/layout-view-discovery.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -2,9 +2,9 @@
22

33
The default order of overrides ColdBox offers is both `viewParentLookup & layoutParentLookup` to **true**. This means that if the layout or view requested to be rendered by a module exists in the overrides section of the host application, then the host application's layout or view will be rendered instead. Let's investigate the order of discover:
44

5-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesViewLookupTrue.jpg)
5+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesViewLookupTrue.jpg)
66

7-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesViewLookupFalse.jpg)
7+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesViewLookupFalse.jpg)
88

99
**viewParentLookup = true**
1010

@@ -20,9 +20,9 @@ The default order of overrides ColdBox offers is both `viewParentLookup & layout
2020
3. Host override common `(e.g. {HOST}/views/modules/myView.cfm)`
2121
4. Default view discovery from host `(e.g. {HOST}/views/myView.cfm)`
2222

23-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesLayoutLookupTrue.jpg)
23+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesLayoutLookupTrue.jpg)
2424

25-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesLayoutLookupFalse.jpg)
25+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesLayoutLookupFalse.jpg)
2626

2727
**layoutParentLookup = true**
2828

‎hmvc/modules/module-inception.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Module Inception
22

3-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/Modules.png)
3+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/Modules.png)
44

55
ColdBox 4 allows you to nest modules within modules up to the Nth degree. You can package a module with other modules that can even contain other modules within them. It really opens a great opportunity for better packaging, delivery and a further break from monolithic applications. To use, just create a `modules` folder in your module and drop the modules there as well. You can also just create a `box.json` in the root of your module and let CommandBox manage your module dependencies. Here is an example of the ColdBox ORM Module:
66

‎hmvc/modules/module-service/module-activation.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,5 +2,5 @@
22

33
Below you can see a diagram of what happens when modules get activated right after registration:
44

5-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesActivation.jpg)
5+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesActivation.jpg)
66

‎hmvc/modules/module-service/module-lifecycle.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Module Lifecycle
22

3-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesLifecycle.jpg)
3+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesLifecycle.jpg)
44

55
However, before we start reviewing the module service methods let's review how modules get loaded in a ColdBox application. Below is a simple bullet point of what happens in your application when it starts up:
66

‎hmvc/modules/module-service/module-registration.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,5 +2,5 @@
22

33
Below you can see a diagram of what happens when modules get registered:
44

5-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesRegistration.jpg)
5+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesRegistration.jpg)
66

‎hmvc/modules/module-service/module-unloading.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -2,5 +2,5 @@
22

33
Below you can see a diagram of what happens when modules get deactivated and unloaded
44

5-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModulesUnload.jpg)
5+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModulesUnload.jpg)
66

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

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# The Decorated Variables
22

3-
![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/ModuleConfig.jpg)
3+
![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/ModuleConfig.jpg)
44

55
At runtime, the configuration object will be created by ColdBox and decorated with the following private properties \(available in the `variables` scope\):
66

‎testing/testing-coldbox-applications/integration-testing/README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ We will begin our adventure with integration testing. Integration testing allows
88

99
### Basics
1010

11-
[![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/HandlerToTestRelationship.png)](https://github.com/ortus-docs/coldbox-docs/blob/master/full/images/HandlerToTestRelationship.png)
11+
[![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/HandlerToTestRelationship.png)](https://github.com/ortus-docs/coldbox-docs/blob/master/.gitbook/assets/HandlerToTestRelationship.png)
1212

1313
Here are the basics to follow for integration testing:
1414

‎testing/testing-coldbox-applications/integration-testing/life-cycle-events.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Life-Cycle Events
22

3-
[![](https://github.com/ortus-docs/coldbox-docs/raw/master/full/images/testing-lifecycle.png)](https://github.com/ortus-docs/coldbox-docs/blob/master/full/images/testing-lifecycle.png)
3+
[![](https://github.com/ortus-docs/coldbox-docs/raw/master/.gitbook/assets/testing-lifecycle.png)](https://github.com/ortus-docs/coldbox-docs/blob/master/.gitbook/assets/testing-lifecycle.png)
44

55
ColdBox testing leverages TestBox's testing life-cycle events \([http://testbox.ortusbooks.com/content/life-cycle\_methods/index.html](http://testbox.ortusbooks.com/content/life-cycle_methods/index.html)\) in order to prepare the virtual ColdBox application, request context and then destroy it. For performance, a virtual application is loaded for all test cases contained within a test bundle CFC via the `beforeAll()` and destroyed under `afterAll()`.
66

‎the-basics/configuration/directory-structure.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ CommandBox>coldbox create app name=MyApp skeleton=AdvancedScript
1010

1111
This will create a Coldbox application with the following structure:
1212

13-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ApplicationTemplate.png)
13+
![](/.gitbook/assets/ApplicationTemplate.png)
1414

1515
> **Info**: Please note that the only required files/directories are `Application.cfc, index.cfm and handlers`. The rest are optional.
1616

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

+1-1
Original file line numberDiff line numberDiff line change
@@ -15,5 +15,5 @@ This is great for intercepting calls, pre/post processing, localized security, l
1515
| `aroundHandler()` | Executes **around** any request action \(In the same handler CFC\) |
1616
| `around{action}()` | Executes **around** the `{action}` requested ONLY |
1717

18-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/eventhandler-around.jpg)
18+
![](/.gitbook/assets/eventhandler-around.jpg)
1919

‎the-basics/event-handlers/locations.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Locations
22

3-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ApplicationTemplate.png)
3+
![](/.gitbook/assets/ApplicationTemplate.png)
44

55
All your handlers will go in the **handlers** folder of your application template. Also notice that you can create packages or sub-folders inside of the handlers directory. This is encouraged on large applications so you can section off or package handlers logically and get better maintenance and URL experience. If you get to the point where your application needs even more decoupling and separation, please consider building [ColdBox Modules](../../hmvc/modules/) instead.
66

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

+1-1
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ Let's do a recap of our conventions for layouts and view locations:
2020

2121
## ColdBox Renderer
2222

23-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/ColdBoxMajorClasses.jpg)
23+
![](/.gitbook/assets/ColdBoxMajorClasses.jpg)
2424

2525
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**:
2626

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

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Layouts
22

3-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/LayoutViewCombinations.png)
3+
![](/.gitbook/assets/LayoutViewCombinations.png)
44

55
A layout is simply an HTML file that acts as your shell where views can be rendered in and exists in the `layouts` folder of your application. The layouts can be composed of multiple views and one main view. The main view is the view that gets set in the request collection during a request via `event.setView()` usually in your handlers or interceptors.
66

‎the-basics/models/README.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -6,17 +6,17 @@ ColdBox allows you to integrate with the model layer with easy by leveraging **W
66

77
Remember this:
88

9-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/spaghetti.png)
9+
![](/.gitbook/assets/spaghetti.png)
1010

1111
Did you get some spine shivers like I just did. WOW! That is the traditional spaghetti coding style. With ColdBox we are now moving into MVC land and focusing on the model layer.
1212

13-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/MVC.png)
13+
![](/.gitbook/assets/MVC.png)
1414

1515
However, the model layer can even be subdivided in many layers as well as we will investigate in this section.
1616

1717
## WireBox
1818

19-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/WireBox.png)
19+
![](/.gitbook/assets/WireBox.png)
2020

2121
WireBox, is our dependency injection and AOP framework, that will do all the magic of building, wiring objects with dependencies and helping your persist objects in some state \(singletons, transients, request, etc\). The main purpose for model integration is to make developer's development workflow easier! And we all like that Easy button!
2222

‎the-basics/models/coding-solo-style/README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Coding: Solo Style
22

3-
![](https://raw.githubusercontent.com/ortus-docs/coldbox-docs/master/full/images/MVC%2Bobjects.png)
3+
![](/.gitbook/assets/MVC%2Bobjects.png)
44

55
Now that we have seen all the theory and stuff, let's get down to business and do some examples. We will start with the full coding approach with **no** ORM and then spice it up with ORM, so you can see how awesome ORM can be. The examples will not show the entire application being built, but enough to get you started with the process of modeling everything. Here is a layout of what we will build:
66

0 commit comments

Comments
 (0)