A quick editorial note. I mentioned last week that I would be playing with Fusebox and trying to learn the basics. In case anyone comes in via Google I wanted to be clear that these are my experiences as I learn. So please be sure to read the comments.
So for my first entry I thought I'd demonstrate the process you follow to install Fusebox. Since this is rather easy, it won't be a long post.
You begin by downloading the Fusebox install files. You can find this on the Downloads page. In case it isn't obvious, you want the download named:
official FB5.1/CFMX core files (v5.1.0)
I don't know why, but the naming scheme kinda threw me for a second. I didn't know that FB was supported in CF, BlueDragon, and Railo, so that's good news if you aren't using Adobe CF.
Unpack the zip, and like Model-Glue, you have two choices. Either extract to your web root, or create a CF mapping. I know folks under ISPs can't use mappings (sometimes), but I don't have that problem so thats the route I took.
As a quick aside, I was looking for install instructions at Fusebox.org, and it isn't on the Documentation page. You can only find it in the zip. (Look for the README.txt file.) Not a big huge deal, but with an easy install I think they should brag about it. Even if it wasn't easy, I think it should be documented on the web site anyway so folks have an idea what to expect.
Next you need (or may need) a basic Fusebox application template. The Fusebox folks call this the skeleton and it too can be downloaded from the site. Grab this file:
Basic FB5.1/CFMX skeleton application (v5.1.0)
Extract this zip into your new web site (or folder), and you are good to go.
And that's it. Nice. As easy as Model-Glue. You can see my skeleton (and yes, I kept it named that because I'm a dork) over here:
http://ray.camdenfamily.com/skeleton
At this point I've confirmed the application runs and I'm calling it a day. Next I'm going to continue on through the documentation and see if I can understand all the files in the skeleton.
Archived Comments
Enjoy Ray, Fusebox really makes a lot of sense once you get into it.
Oh can I recommend that you stay with a MVC approach that you get with the skeleton app, it just keeps everything neat. Incedently the skeleton app isn't needed :)
On a note not specific to Fusebox but covered in your post, I personally don't like the use of mappings to handle resolving the location of the core files, regardless of issues at the host. I think they should be under the root. The reason is because we still don't have application specific mappings in CF (this long overdue feature in Scorpio perhaps? One can only hope). Thus, if you build two apps, one with Fusebox 4.1 let's say and one with 5 - how do you resolve the different versions with a single mapping? You can't obviously.
Anyway, sorry to sidetrack the comments, but that is an issue stood when I read the post.
Wow, I can't believe you've never dabbled in this before. Fusebox rocks, especially 5.0+. It'll satisfy the needs of 90%* of your applications.
*I made that number up. It represents the unquantifiable figure, "most."
Brian, just curious: why would you particularly need the same mapping? I have apps on my server running on different versions of FB, the core files for which are under a "/library/" mapping (i.e "/library/fusebox4/", "/library/fusebox5/") and I find it useful to see from the app's mapping which version it's using.
Maybe I've missed your point.
@Nick, one benefit of unpacking the skeleton app is that you can get at the errortemplates and lexicon examples.
@Brian, as Julian said you can make a mapping for each version of Fusebox and change the root directory called in the index.cfm file. Personally I created fusebox510b1, fusebox510b2 directories and mappings and moved app's up as I became confident with the stability of the core. The final version obviously was located/mapped in fusebox510. This give me the option to have a possible fusebox511 or fusebox512 some time in the future if needed.
I suppose this is my ignorance of Fusebox specifically...good to hear it isn't an issue in this case. However, every framework I have experience with requires either a mapping to the core files or for the core files to be directly under the root in which case you do encounter the issue I discussed.
Hey Thanks! Welcome to Fusebox... it´s really a good framework and helps a lot....
I typically look for the documentation on a site while the item is downloading. low attention span I suppose. but I agree with Ray. :)
@Brian: Brian, what I've done in the past to make code more portable between file locations is to code the mapping as a variable (ie, "/#VARIABLES.mapping#/page.cfm", which would resolve to "/library/page.cfm", which is then resolved as a mapping by CFMX. The application.cfc can set the correct mapping for each application on the box, and thus you can transfer code between apps if you need.
Fusebox - even with CFCs in release 5.0 - has always allowed you to include the core files via a relative path, e.g.,
include template="../../fusebox/fusebox5.cfm"
Fusebox creates the core CFCs by relying on local relative paths - which is why all the fuseboxXxx.cfc files are in the same directory as fusebox5.cfm.
As for Getting Started / Install docs, good point. We have a team of people leading efforts to improve everything about Fusebox from the website to the docs to the core files to the sample apps to...
This is not your father's Fusebox :)
Something else to remember is what comes with what - in terms of the download packages. The skeleton (as already pointed out) comes with errortemplates and lexicons whilst the core download is simply that - core files.
Couple of things to point out here - prior to fb5 you couldn't have multiple Fusebox applications in the same cf application name space - they'd overwrite each other when they ran (now you just set <cfset Fusebox_Application_Key = "myapp"> in your application index.cfm). Remembering what came with what then, with fb5 errortemplates/plugins/lexicons were unique to the specific fusebox application so you could end up multiple copies of errortemplates/plugins etc - particular in a corporate intranet where you may have multiple fusebox applications. With fb5.1 these can now be shared amongst multiple applications so you don't need multiple copies of errortemplates/plugins/lexicons etc...
Ray, these walkthrough's are a great idea. Thanks for sharing.
Created Fuseboxipedia.com, if for nothing else my own sanity when it comes to fusebox doc info.