coldfusionJedi

This entry was posted on Monday, February 5, 2007 at 3:36 PM. It was filed in the following categories: Fusebox. It has been viewed 5,709 times and has 14 comments.

TweetBacks

Comments

[Add Comment] [Subscribe to Comments]

• Comment 1 written by Nick Tong on 5 February 2007, at 4:32 PM

  

  Enjoy Ray, Fusebox really makes a lot of sense once you get into it.

• Comment 2 written by Nick Tong on 5 February 2007, at 4:37 PM

  

  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 :)

• Comment 3 written by Brian Rinaldi on 5 February 2007, at 8:12 PM

  

  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.

• Comment 4 written by Paul on 6 February 2007, at 1:08 AM

  

  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."

• Comment 5 written by Julian Halliwell on 6 February 2007, at 2:13 AM

  

  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.

• Comment 6 written by dickbob on 6 February 2007, at 4:27 AM

  

  @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.

• Comment 7 written by Brian Rinaldi on 6 February 2007, at 6:14 AM

  

  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.

• Comment 8 written by Diogo Moura on 6 February 2007, at 8:23 AM

  

  Hey Thanks! Welcome to Fusebox... it´s really a good framework and helps a lot....

• Comment 9 written by DK on 6 February 2007, at 9:21 AM

  

  I typically look for the documentation on a site while the item is downloading. low attention span I suppose. but I agree with Ray. :)

• Comment 10 written by Tom Mollerus on 6 February 2007, at 11:53 AM

  

  @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.

• Comment 11 written by Sean Corfield on 6 February 2007, at 11:20 PM

  

  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 :)

• Comment 12 written by johnb on 7 February 2007, at 7:36 AM

  

  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...

• Comment 13 written by Charlie Arehart on 8 February 2007, at 9:21 AM

  

  Ray, these walkthrough's are a great idea. Thanks for sharing.

• Comment 14 written by Josh on 23 January 2008, at 2:41 PM

  

  Created Fuseboxipedia.com, if for nothing else my own sanity when it comes to fusebox doc info.

[Add Comment] [Subscribe to Comments]