May 10
‘Why move to XML?’ was one of the questions posed to me when I was up in Scotland a few weeks back talking about Fusebox4.1. I think there potentially a number of reasons;
- Platform Portability - hmm, touted as a reason but I wonder how many people have built a Fusebox 4 application on CF and then moved it over to PHP. Granted having the single XML language for all platforms makes the application ‘readable’ by all developers at a Fusebox level but i don’t consider that as a primary reason
- Reducing logic at circuit level - moving the circuit definition files from using a CFSWITCH in Fusebox3 to an XML definition in Fusebox4 meant we can no longer use CF code in our circuit definitions, thereby reducing the amount of logic and forcing more of it into the individual fuses. We now have a limited grammar which we can use within the circuit definitions so we should all certainly be able to ‘read’ each others applications at the circuit level - but custom lexicon kinda throws a spanner in the works to this reason.
- Performance? Does getting rid of the CFSWITCH indeed increase performace? I wonder i if Fusebox4 had retained the cfswitch and got rid of all the other stuff, nested settings, circuit etc and brought in the stuff FuseQ introduced - how would it perform?
- cos XML is cool? Well yes it is, but when Fusebox 4 came out it was built on CFMX6 - with that we got CFCs - Fusebox 4 could have gone down the XML/CFC route (in fact I still have an unreleased version using CFCs and XML which ultimately led to MachII) but it was seen more prudent to keep Fusebox procedural and leave the OO stuff for MachII
May 01
just got in from my long weekend up in Edinburgh thanks to the Scottish CFUG and Edinburgh University. I think both presentations went well, we certainly had some good discussion and good questions raised - these will be subsequent blog posts. Huge thanks to all that arranged the trip - you know who you are!
Mar 13
Jared’s post here caught my eye. It’s an interesting concept although as he says himself - ‘a possibly pointless Fusebox tool’ may be true. I’m not sure why you’d want (or need to) mess with the application.fusebox structure at runtime - I’ve certainly never needed to. Since application.fusebox is pretty much ‘frozen’ when you change an application from development into production mode messing with the structure seems a risky business.
Mar 07
My cell phone rings…
me: Hello
courier: Hi, I’m from DHL and I’m outside your flat and have a packet for you
me: well I’m at work right now, who’s it from?
courier: not sure, it’s small and in a yellow and red packet
me: no kidding?
I mean honestly, a DHL courier telling me a package is in a yellow and red packet? Doh! Anyway, turns out it was a copy of Discovering Fusebox (the second edition) that was being delivered which is actually for a prize giveaway at my Scottish CFUG Fusebox presentation in April - might try and flick it though(carefully!)
Feb 25
I’ve just seen that not only does shop.vodafone.co.uk use ColdFusion but it’s also using Fusebox!!!
Feb 14
Sean has already blogged this but Stephen Judd has just posted a cool Firefox extension that allows you to reload the Fusebox XML from a simple right click and entering your fusebox.xml password - grab the extension here and try it out.
Feb 05
As Andy has blogged here it’s been finally confirmed I will be speaking to the Scottish CFUG in Edinburgh about Fusebox4.1 on Thursday April 28th. I’m spending the Thursday afternoon with Edinburgh Uni before presenting to the CFUG in the evening. I’ll be up in Edinburgh for a few days after too to do a bit of touristy stuff in the city.
Jan 18
This thread got me thinking about using framesets with Fusebox4.1. Now, I’m not a big advocate of framesets but they do have their uses (on occassion). I’ve used them with Fusebox3 but haven’t needed to use them with Fusebox4.x.
It’s important to remember that the fact that you’re using Fusebox to structure your application is irrelevant, frames will work just the same - you just need to think ‘Fusebox’ when you’re calling your frameset and remember the problems that you may encounter. A typical Fusebox HTML frameset call will look something like;
<frameset cols=“436,436“>
<frame src=“index.cfm?fuseaction=frametest.left”>
<frame src=“index.cfm?fuseaction=frametest.right”>
</frameset>
Coupled with this, you need a fuseaction that will initialize this frameset - if you’re running your entire site in frames then the default fuseaction is a good place to do this, so you might end up with a fuseaction called ‘frameset’ that calls a template named fra_setup.cfm that included the above code. Rather than specifying individual files for each frame source you send the request back through the Fusebox to the associated fuseaction to load in a specific frame.
It’s all well and good but you HAVE to remember the caveat. When your frameset runs it will initiate as many HTTP calls as the number of frames you’re calling - that means in development mode you overwrite the application scope every request so you can end up with one request over writting another. As Sean ends the quoted thread you can fix it by switching to production mode - but in a development environment it’s something to be mindful of.
I wrote a simple 4 frame test to see if i can make it trip up but i couldn’t - even in development mode…
Jan 07
It’s finally here, grab yours from here
Jan 05
So fingers crossed the 4.1 cores will be gold very very soon, but just in the nick of time another tweak has been made before they go final.
I ran into a situation the other day where i’ve got a couple of preprocess fuseactions running globally dumping into a CCV (to produce my blog sidebar) so they always appear in my layouts. So far so good - but i then needed to add an item to the sidebar ABOVE the global FAs. Ahh…well you could do it with FuseQ but with the native grammar you needed to go via an additional variable, eg
<fuseaction name=“test”>
<include template=“dsp_test” contentvariable=“MainCCV” />
<do action=“sidebar3″ contentvariable=“RightCCV2append” />
<set name=“RightCCV” value=“#RightCCV2append##RightCCV#” />
<do action=“layout.apply” />
</fuseaction>
RightCCV is the name of the CCV in my layout with the global FAs already in it, so i then set the value of RightCCV to be the result of the FA i want prepended and add the orginal content behind it, kinda clunky huh?
Well, now in addition to the append=”true” attribute you can do prepend=”true”, so the above simply becomes;
<fuseaction name=“test”>
<include template=“dsp_test” contentvariable=“MainCCV” />
<do action=“sidebar3″ contentvariable=“RightCCV” prepend=“true” />
<do action=“layout.apply” />
</fuseaction>
Hopefully i’m not the only one that will benefit from that little tweak…
Recent Comments