Archive

Posts Tagged ‘fusebox’

Fuseboxing progress – Navigation menu

July 24, 2009 Leave a comment

I’ve been working to convert my church’s old site to Fusebox 4 for ColdFusion in order to get cleaner, more modular code and to make maintenance simpler for parish staff.  I started off diagramming a database schema in which the content would be stored.  This got me thinking about just how the site would work when finished.  I then dropped the core FB4 files into my local webroot and started working.

With a schema in place, I was able to determine the necessary circuit.

  • home – this is the default circuit
  • sections – drives the navigation menu
  • pages – handles page content
  • news – drives the news module
  • links – drives the links module
  • contacts – drives the parish contacts module
Current static navigation menu

Current static navigation menu

I began with the sections circuit and began coding fuseactions. The sections circuit will be the foundation for the navigation menu.  Each section corresponds to a link in the navigation.  I added a ‘parent’ to facilitate subsections which will appear as flyouts.  I then began writing the sections CFC which will access the data.  The section CFC contains your basic CRUD methods and one special method to handle subsections.   Right now, since there is only test data in the DB, the menu isn’t fully populated with subsections.  I should note, that I first considered using the built in ColdFusion 8 <cfmenu> and <cfmenuitem> tags to generate the menu.  I actually built the menu, but then decide to go back to the CSS/JavaScript that is used in the current site.  All I had to do was invoke the section CFC to display the section data as links in the navigation menu.

Dynamically generated fusebox navigation

Dynamically generated fusebox navigation

Using the Frameworks explorer in CFEclipse, it was really easy to create circuit files and their corresponding fuseactions.

Advertisements

From Contribute to a Custom CMS

July 24, 2009 Leave a comment

I relaunched my parish’s web site 3 years ago using ColdFusion 6 and let staff maintain the site using Contribute.  This was no problem at the time as the site was small and had a fairly small audience.  Contribute was a quick and easy solution for the 2 parish staff to make updates to the site and it has worked well these 3 years.  I was still a novice programmer and had not come to realize the power of CFCs or even any of the many CF frameworks out there.

Current site

Current site

The time has come, however, for a serious site overhaul for a few reasons.

  1. The staff has grown tired of Contribute because it ties them to a single machine for updating the site.
  2. Site usage has increased tremendously
  3. The site has become cluttered with old, outdated content that in most cases is no longer needed
  4. Our host was not very reliable.

I first focused on open source blog and CMS software for our solution.  The CMS packages generally fit into two categories:

  1. Far too complicated
  2. Small feature set even for our fairly basic needs

After lots of trial and error, I decided to build my own custom CMS.  I use Fusebox 4 in my daily work, so this was a logical choice.  The front-end code can be organized and easily maintainable.  Content will be stored in a database, likely MySQL or SQL Server, and an administrative module will be used for content maintenance.  I’m going to use Flex 3 to build the admin module, which will allow staff to add, edit, and delete content from any machine with Internet access.

I’ll periodically update with my progress.

My life as a CF developer

June 20, 2008 Leave a comment

I am currently employed as web application developer at the Academy for Educational Develoment(AED) in Washington, DC.  AED uses Fusebox 4.1 for its ColdFusion development.  I was familiar with Fusebox, having toyed with it a few years ago back in Fusebox 3, so I wasn’t coming in totally cold, but pretty close.  During my first week, I did a lot of reading due to the fact that my laptop had not arrived; I was hired right after the holidays and things moved much faster than their normal hiring process with the exception of the equipment.

Now that I’ve had 6 months to get used to it and use it at least two different ways, I can confidently say that I like this framework.  We do not use Fusebox in an OO fashion as is becoming a trend these days.  Rather we are still procedural for the most part, but we do use CFCs for most of the newer applications.  I really like using CFCs in my code because it centralizes my queries and business logic.  What I have noticed, however, is that even among the three of us, we have different styles in our use of CFCs, particularly in how we call them.  One likes to use the old fashioned:

<cfset someVariable = path.to.component.method(arguments) />

This is perfectly acceptable and demonstrates a saying I often use in application development.  “There’s always another way to achieve the same task.”  The problem I have with accessing my components in this manner is that it doesn’t explicitly name the arguments as they are in the CFC.  In fact they could actually be different.  Additionally, it seems you have to pay close attention to the order of your arguments as you pass them to the component.  I inherited an application from my coworker and had to add a new argument, but didn’t pay attention to the order in which they were passed.  This resulted in an error in the function that wasn’t obvious at first.  Only after a little troubleshooting did we figure it out.  For this reason, my preferred method of calling my components is:

<cfinvoke component=”#componentName#” method=”methodName” returnvariable=”returnvariableName” argument1=”#argumentName#” argument2=”#argument2#”/>

Perhaps this is a holdover from my hatred of math.  I am very methodical and was never the kid who could skip steps when solving a math problem.  I had to work out each step in order to arrive at the solution.  Using the above method allows me to clearly and precisely state the component and method I am calling, as well as declare each argument I am passing in and naming the variable I will use to refer to the results of that method after execution.  It helps me when writing the act_ or dsp_ file using the data from whatever method to know this information up front.

I mentioned that we do not use CFCs in an object oriented fashion.  We tend to group our CFCs by circuits, usually with once CFC per circuit.  Additionally, it likely we’ll have one Lookup CFC to handle frequently used methods such as querying a lookup table for US States, or Regions, or Countries, or Months, etc.  In this way we can have those methods execute once and be available for whatever page might need them.

Using CFCs in this manner probably is not a best practice.  In fact, probably just the opposite, but it does work for us.  It does, however make for some very long CFCs.  I have a 500 line CFC in my current project.  Thank goodness for the CFC explorer in Eclipse, which makes it ever so easy to jump to a specific method. I have just recently learned about the CF Frameworks explorer in CFEclipse, which I’m finding extremely useful to not only explore the application from a single, outline-style list, but also as a means to help in writing my fuseactions for my circuit files in a slightly more organized way.