Objective Action - Conversion

Converting an Application from Fusebox 3 to Fusebox 5.5 (Part 3)

Fri, 25 Apr 2008 11:17:00+0100

I have now got several circuits working in my application and as a result have developed a kind of methodology for doing the conversion. As wel as the items mentioned in the earlier posts there are a number of changes required.

Content Variables and Layout

The first is that since my fusebox 3 application was using the nested circuits I have to put all my display includes inside a cfsavecontent tag. For the moment I don't want to make any big cahnges to the application and it does not use MVC so I can't make use of the do facility to put the output of those fuses into the content variables. Fusebox3 put everything into a variable called fusebox.layout which was in variables scope. Since I don't have easy access to variables scope I decide to use a request scope variable which will be available in my circuit CFCs. In my case I am using request.page.content mostly because that is the name used in some applications I have.

The same variable has to be used in the layout files and in the fbx_layout I actually have to include the file as it is no longer done automatically for me.

Fusebox Variables

There are several places in the code where I have used Fusebox.Fuseaction and this needs to be changed to MyFusebox.OriginalFuseaction. To make this work I also need to add the argument tag to every method in that needs it.

Attributes Scope

All my existing fuses expect to find the data that was in form or url scope in the attributes scope. By adding a line in the prefuseaction I can copy that from the arguments in one place.



	
	
	
......

I hope these notes are proving useful to anyone planning a similar conversion. Do let me know.

Converting an Application from Fusebox 3 to Fusebox 5.5 (Part 2)

Thu, 24 Apr 2008 08:42:00+0100

Converting the circuits

I can see this part of the conversion being a bit of a slog. In each fbx_switch I have to do the following steps:

Change the cfswitch tag to a cfcomponent tag. (Don't forget the closing tag too!)
Add a prefusaction to call the circuit's fbx_settings fuse and because we no longer have the automatic nesting available we have to call the parent circuit's fbx_settings fuse.
Add a postfusaction to call the page layouts. Again I have to remember to add the fbx_layout for any parent circuits.
Move the changed code (now a CFC) to the controller directory.
Then because the circuit CFC will now sit in the controller directory I have to put the path in front of every cfinclude template parameter. (But see insight below).

I worked my way throught two of these circuits, they were small ones but even so some of the changes are tedious and the path changes are not too easy to automate. But at the end of that work two of the circuits from my application are working and running under Fusebox 5. No major fuses have been harmed, apart from moving some of the code from application.cfm to application.cfc, and some of the initialisation code from fbx_settings into application.cfc. Then I had an insight! It isn't really necessary to move the fbx_switch code to the controller directory! I could avoid having to add all that path information to the includes. I can just leave my new circuit CFCs where they are with their fuses in the same directory and create a dummy CFC which just extends the new circuit CFC to put in the contoller directory. Problem solved! Now most of the required changes are automatable and a global search and replace should do it! I'll let you know what I find.

Converting an Application from Fusebox 3 to Fusebox 5.5

Wed, 23 Apr 2008 10:13:00+0100

Old applications never die, at least the one I am working on refuses to. It was written a while back and uses the Fusebox 3 framework. As we add more and more to it, it's getting more difficult to manage, so I decided to bite the bullet and convert it from Fusebox 3 to 5.5. I had previously avoided upgrading to Fusebox 4 or 5 because there would have to be a lot of changes. Going from 3 to 4 wasn't easy. I did several conversions and they all took a long time and the limitations of Fusebox XML always meant that some clever stuff I had in my code had to be completely redesigned. The limitation of not being able to nest or tags in Fusebox 4 circuits was really a problem, as I had often done that in my fbx_switch (circuit) files which were written in CFML. Don't get me wrong, I do like Fusebox XML now that I am used to it. If you start from there that's fine but converting something from Fusebox 3 is a bit different. Fusebox5.5 has one big advantage. It will let me use CFCs as circuits and they are written in CFML so I should be able to simply move the code from the fbx_switch to the CFC. That shouldn't be a problem. So, yesterday I began the task and the first issue I came across was that in order to use CFCs as circuits I was forced to let Fusebox find my circuits for me. I started out deciding I was going to have a fusebox.xml file but that has no way to support CFC based circuits. So I got rid of the fusebox.xml and converted the first fbx_switch.cfm file to home.cfc. The next issue was file placement. The original application had a number of directories each with it own module. In some cases it has subdirectories that make use of the nesting idea that was in four at the time. For example there is an Admin directory which has a number of subdirectories one for each area of the application. This nesting of content is no longer done that way but there is a good reason for leaving the directory structure unchanged. I expect the conversion will take some time and the original application will continue to evolve in the meantime, so I want to eventually do a CVS merge of any changes. For that to work the locations of all the fuses really has to stay the same. I consulted the documentation and then the guru and found that there is no way for the CFC based Fusebox to support that directory structure. The original application also does not use MVC because in Fusebox 3 there was no big advantage from separating the application that way. I know Hal was preaching it, but at that time I thought it was really difficult and I didn't see any big benefit from the extra overhead. I decided that eventually I do want to use MVC so it makes sense to go in that direction so I have created a controller directory in which to put the new CFC based circuits. Since I already had the framework installed on my machine, Step 1 was to create a new CVS branch and take one of the fbx_switch files and convert it to a CFC. In the short term I won't create a model or view as I just want the existing to code to work with minimum changes as a first pass. By the end of the day I had my first fuseaction working. There were a number of wrinkles. The first was the surprise of seeing this error message: This is just a case of RTFM and the answer is to set some Fusebox variables to turn on the no XML mode of operation and set the default page.

The second was that I was't seeing all my HTML. The original application makes heavy use of <cfsetting> in an attempt to avoid whitespace. There was obvoisly a difference between the old and new structure I had created and there was not enough <cfsetting> tags. Adding an extra one solved the problem but the whole lot will need sorting out. I generally now use <cfsilent> instead as I find it more reliable and easier to code. I'll let you know how I get on.