I was just playing about with Selenium and wondering how I could be sure that I tested all the fuseactions in my application. The application has been converted from an old Fusebox 3 application and the original test scripts were written a long tiem ago and were the kind where you had to manually do everything. Since then some major changes have happened to tha application and the test script has not been updated.

It seemed to me that it should be possible to easily get a list of fuseactions from the application itself. From there it was only a short setp to creating the test script.

[More]

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

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

Attributes Scope

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

Converting the circuits

• Change the cfswitch tag to a cfcomponent tag. (Don't forget the closing tag too!)

Change every cfcase tag to a cffunction tag and the value= to name=.

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

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.

On Thursday 17th i will be giving a short presentation on Fusebox Scaffolding to the CFMeetup Online ColdFusion User Group.

Its a preview of a longer presentation I will be doing at CFUnited Europe on 12th and 13th March 2008.

If you would like to see it please sign up at CF Meetup site.

I finally got time to work on this again after a few weeks of hectic madness, which included passing my Coastal Skipper exam and visiting my sister for a weekend. I spent Sunday afternoon and yesterday evening generating code using the ColdSpring Templates and finding the bugs in the generated code. Then I found the place where the bug was generated and fixed the template.

Its quite tedious as on my laptop it takes a couple of minutes to regenerate the application with my test database.

I have uploaded what I have done so far to SVN as it makes my life easier to download it all from SVN onto the various machines I have to test it on. There are probably still bugs in the ColdSpring templates and I know that in the process I have broken the Reactor Templates.

I also changed the order that code is generated in. This is mostly for my own benefit as I was finding it difficult to find things. In the past code in the circuit.xml file was generated in order of fuseaction then object. Now its in alphabetic order of object then fuseaction. This means that all the fuseactions related to a particular object are next to each other.

The new Fusebox 5.5 will be realesed on December 1st so I am working to get my changes and fixes complete by them but I suspect the scaffolding will still be in Beta at that point as I haven't had as much opportunity to test as I would have liked. I been installing new servers or updating old code to later versions of CF rather than developing new code.

You can get the latest code version from SVN at: http://svn.fuseboxframework.org/framework/branches/dev/extensions/scaffolding

A couple of fixes have been posted to the scaffolding code alpha on the fusebox website. The most important was a missing template file for the coldSpring templates.

Anoter addition is the documentation which got missed off the original release. The word doc contains instructions on how to write your own templates. It still has some big omissions and will be updated with a complete API in future releases.

There is still an unfortunate need to change the directory that the code is installed in, but I am planning to fix that by the time the next release is available. For the present please be sure to read the readme.txt file.

If you do experience any issues please try to be specific about the problem, as I can't help if you tell me only that it does not work. If you need help please send me a copy of the error message and it also helps if you can send a copy of the generated sacffolding.xml file too.

Remember this is still an alpha version so all bugs are not yet found and tracked down.

Good Luck!

If you read Part 2 of the series you might have seen Peter Bell's comment about the best way to use the code generated by scaffolding. Ok, so wouldn't it be great if the scaffolding was good enough to use without any change? Unfortunately the current templates available with the Fusebox scaffolder are likely to produce code that is less than complete. There are several areas where you will find it possible to improve the code. Lets look at each in turn because this situation is one where the answer may vary slightly in each case.

[More]

So you want to use an architecture to avoid those nightmares. Unfortunately its not easy to get started. Unlike building a single page web site you have to create a lot of stuff before you even see anything. In Fusebox 5.1 with MVC you have to create a view directory with a dsp_ fuse, a controller directory with a circuit.xml, in the root goes a fusebox.xml and you define your application name in index.cfm before you get close to seeing the magic words "Hello World". If the words are going to come from a database you have to create a model directory and a qry_ fuse too.

So what if your application does more than output "Hello World"?

[More]

Yesterday at MAX Sean Corfield announced the release of Fusebox 5.5 Public Beta.

There is a new page on the Fusebox web site with links to all the modules.

One of the modules vailable on the beta page is my scaffolding code which is not strictly a Beta as its currently in Alpha. If you would like to take part in Alpha testing please let me know. I am keen to see people using the tool to generate applications and to get as many of the bugs as possible in the current code tracked down before we start adding the features for the next Alpha 2 version which should include some other databases.

Sean has also put the Fusebox 5.5 release notes on Share so demostrating the usefulness of the new service.

You need scaffolding!

So you read something somewhere that said you should be using scaffolding and want to know how? Let me tell you a story.

ColdFusion has been developed to make creating applications easier right?

[More]