|By Brian Hostetler||
|October 6, 2005 05:45 PM EDT||
Recently, during a Hal Helms training session, I started to look for ways to automate some of the drudgery of my upcoming application.
After Hal talked about mindmaps, he began creating the four circuits and perhaps a dozen fuse files for the application. In 45 minutes, he created the folder, files, and fusedocs. I began wondering: Would it be possible to automate this, thereby cutting down on the mindmap-to-fusestub phase?
An online search for automated tools written to automate this process led me to Jeff Peter's grokfusebox Web site (www.grokfusebox.com). I downloaded and unzipped Jeff's tool, FuseMinder for FB4. FuseMinder reads a mindmap file and creates the directory structure and files on the server. After altering my mindmap to fit Jeff's specifications, I gave it a whirl and, to my enjoyment, it worked great! All of my folders were created in the way I intended, and all of the fusefiles were created and had fusedocs already written for them.
I noticed something, though. In my mindmap, I had included both incoming and outgoing variables in the mindmap's notes section. Hal had explained that during the creation of the mindmap was the best time to identify these variables, prior to their inclusion in the fusedocs. However, if the information to help build the fusedocs is put in the notes section of the mindmap, why didn't FuseMinder use them to create the fusedocs?
After delving into the code of FuseMinder, I noticed that the tool was parsing the text entered into the notes section, placing it at the end of the fusestub. However, this was the very information that would eventually need to be the fusedoc itself. Couldn't the program be modified to handle this automatically?
I e-mailed Jeff Peters to discuss my idea with him, and from our chain of e-mails it became clear to me that one reason this was done was so that a portion of the HTML front end could be added to the mindmap and then parsed into the fuse by FuseMinder. In this way, the front end of the project was mostly complete; all the coder had to do was wrap the HTML in ColdFusion to make the display dynamic. I thought this was a great idea, but also thought that it could be expanded on.
The idea that I had was to modify FuseMinder in such a way that it would create all of the fusedocs for the architect, therefore allowing them to stay in the mindset of an architect. We all know what happens when you start switching from one task to another: none of them get done exactly the way you would like. It's too easy for our thought processes to become muddied when switching tasks.
With this task in mind, I took another look at the FuseMinder code. I found where the notes section of the mindmap was parsed and noted how the original FuseMinder handled it. From there I modified where FuseMinder sent the notes text, then searched for specifically formatted text. Confused? Let's look at an example.
Figure 1 shows a section of a mindmap outline file created by Visual Mind.
Notice the lines formatted like this:
IN:string:userName:comment=This is the username:scope=attributes
This line of code represents an incoming variable to be placed in the "in" section of the fusedocs. My modified code resulted in the following fusedocs tag:
<string name="userName" comment="This is the username" scope="attributes" />
There are three types of taglines that the code I wrote will recognize. Any lines that start with IN, OUT, or RESONSIBILITIES followed by the correct syntax will be parsed into the correct section of the fusedocs. Anything else will be treated as a note and placed below the fusedocs. This allows the architect the same flexibility that Jeff Peters wanted - being able to place HTML into the mindmap outline where it can be translated into the fusestub.
Let's look at each of the three recognized keywords and their syntax. Note that all of the lines are delimited by colons (":"), just like the nodes in the mindmap, providing the architect with a common delimiter throughout the mindmap process.
The RESONSIBILITIES keyword allows the architect to supply the fusedocs with custom text for the responsibility of the fuse. Just place the free text after the keyword and the delimiter. Once you have completed the text, enter a carriage return to show the end of the line.
The IN and OUT keywords expect the same syntax following the keyword. The next entry should be the data type of the variable. This could be string, number, recordset, or any of the other fusedoc's variable types. After the type comes the name of the variable. This is free text, but should be a valid variable name for ColdFusion since it will eventually be used in code.
Up to now, everything that I have mentioned is required. But, as you may know, fusedocs allow many more fields in their variable declarations, such as comments, scope, etc. To account for this, these extra fields can be entered following the variable name. To do this, simply enter something similar to "scope=attributes" and the "scope="attributes" field will be placed into the fusedoc.
Let's take another look at the complete mindmap outline that's shown in Figure 1. When you run FuseMinder with these changes on the outline, the following directory structure will be created (see Figure 2).
Within these directories are the fusestubs for all of the fuse files we specified in the mindmap file. For those of you new to FuseMinder, these are the nodes marked with "ff:". Opening the fuse file shown in the sample outline in Figure 1, dspCreateUser.cfm, reveals the fusedoc shown in Figure 3.
You can see that all of the incoming and outgoing variables specified in the mindmap outline are placed in the fusedoc and that there are no parts of the fusedoc left to be completed. This fusedoc can be passed directly to a coder and completed without any further work from the architect.
There is one other area that I have not covered - coding any structures and/or recordsets into the mindmap. When you need to enter either a recordset or structure data type, place all of the fields on separate rows starting with "-",using the colon delimiter to separate the field name and data type. To show this better, let's review an example.
Say you are expecting an incoming recordset named qryUser with columns of userID (number) and firstName (string). This is what you would enter in the mindmap:
This would create the following in the fusedoc:
<number name="userID" />
<string name="firstName" />
By using this code and a properly formatted mindmap outline, any architect can run the outline through FuseMinder and be done with the architecting process much more quickly; the drudgery of creating the full directory structure and fusestubs is handled automatically.
Last, I want to thank Jeff Peters for the work he has done with creating the FuseMinder tool and for taking the time to discuss the process with me while I researched my ideas. I also want to thank Hal Helms for discussing the problems he saw in the process and helping me think through the entire process completely. I hope that the research I have done will be a help to the Fusebox community. If you are interested in seeing any of the files that I have included here, or would like the FuseMinder code that I am using to create the full fusedocs, or just want to discuss these ideas with me, feel free to e-mail me at email@example.com.
|CFDJ News Desk 12/06/05 06:49:18 PM EST|
Recently, during a Hal Helms training session, I started to look for ways to automate some of the drudgery of my upcoming application. After Hal talked about mindmaps, he began creating the four circuits and perhaps a dozen fuse files for the application. In 45 minutes, he created the folder, files, and fusedocs.
- Where Are RIA Technologies Headed in 2008?
- The Next Programming Models, RIAs and Composite Applications
- AJAX World RIA Conference & Expo Kicks Off in New York City
- Constructing an Application with Flash Forms from the Ground Up
- Building a Zip Code Proximity Search with ColdFusion
- Personal Branding Checklist
- CFEclipse: The Developer's IDE, Eclipse For ColdFusion
- Has the Technology Bounceback Begun?
- Adobe Flex 2: Advanced DataGrid
- i-Technology Viewpoint: We Need Not More Frameworks, But Better Programmers
- Web Services Using ColdFusion and Apache CXF
- Passing Parameters to Flex That Works