Archive

It’s been quite some time, actually years since I posted to this blog. I’m not entirely sure why that is. I’m still a web developer, learning new things. This will mark my return. Though much has changed work wise over the years, I still do the majority of my coding with ColdFusion. However, I’ve recently taken up expanding my developer’s toolbox. I’ve dabbled in PHP, Java, and most recently Ruby and the Rails framework. I use PHP only a little bit at work and some time in the future it could become our next platform if we move away from ColdFusion. However, I’m really excited about Ruby on Rails (RoR). This is not my first time using RoR. Years ago I gave it a try but for some reason I found the learning curve to be too steep. However, having used the CFWheels framework which borrows heavily from RoR both syntactically and philosophically, it makes so much more sense. I also have a much better understanding of OOP. Work is giving me lots of freedom to explore and choose what I like which is great. There are so many great tutorials out there it’s hard to know which ones are good and which ones to avoid. For now I’m going with what seems to be the definitive beginner’s tutorial, The Rails Tutorial. The next few blog posts will likely concern concepts as I work through building the sample app in the lessons. Hopefully, I write something others find useful.

Continuing with my CFWheels powered Forum application, I had a desire to include a thread count and a post count for each forum listed on the main forum page. In my old spaghetti coding days, I would first have used a retrieveForums query. Then in my display code, while looping over the retrieveForums recordset, I would then query the threads table passing in the forumID foreign key to obtain a thread count for each forumID. In a similar fashion, I would get a post count for each forumID. The code below illustrates this scenario.
<cfquery name="getForums" datasource="myDSN">

SELECT * FROM forums

<cfquery>

<cfloop query="getForums">

<cfquery name="getThreadCount" datasource="myDSN">

SELECT COUNT(*)

FROM threads

WHERE threads.forumID = #getForums.id#

</cfquery>

</cfloop>

While this is not the CFWheels way, I found out that it is very easy to convert this code into CFWheels syntax with the same results.

Enter Calculated Properties. Searching the CFWheels blog and documentation, I was able to find this little gem which allows me to assign additional properties to a given object based on a SQL query. In this manner, property then becomes part of that object without the need to loop over a query to retrieve it as in the above code block. This property can then be called just like any other property of that object. Honestly, I’m not entirely sure I worded that correctly, but the bottom line is the result is the same as my spaghetti code example. Let’s look at the new code in my forum model.

I know I’m really late, but I’m just now getting around to switching to CFWheels 1.1. I guess being over forty, I’ve become set in my ways. I love CFWheels already. Why does it have to change? Enough already. I’m taking the plunge. A while back I had started on a very simple forum application for work. The forum is based on an old tutorial project I had worked through on EasyCFM.com. I thought it would be a good idea to do it using CFWheels. Due to legacy code issues, I had to abandon that effort and use spaghetti CF code, but I kept the work I had completed in CFWheels 1.0 thinking I could come back to it later one day. That day is here, but I think before I resume, I will update to CFWheels 1.1 and then work to finish the forum.

Forum Application Built on CFWheels 1.0

First up, download the new framework code. Simple enough. Visit http://cfwheels.org and download the files. I notice that I’m so late, they’re already up to 1.1.2. I’ve got some catching up to do. They also have provide an Upgrading to Wheels 1.1.x guide which states that all that is really necessary to upgrade is “replace the wheels folder with the new one from the 1.1 download.”

My first step will be to upgrade the application to CFWheels 1.1.2. Once I have it back up and running, I will then continue with development. The goal is to create a forum with many of the common features we have come to expect in a forum application. I hope to learn about the new features of CFWheels as well as to create a useful application. I’ll add new blog posts throughout development.

It seems like it’s been forever since I started working to create my own CFWheels version of the LitePost blog application. Work and life interrupted me along the way, but I managed to finish what I’ll call a first version. Ironically, the hardest part seems to have been trying to get it into some sort of version control and accessible for others. Figured that out, I think, and it is now available on GitHub. I will share some highlights and thoughts of the project.

LitePost using CFWheels

Worry about functionality first. The design can be worked out later.

Early on, I decided to work with text only. However, I found myself thinking, “This doesn’t look like a blog.” I then interrupted coding the blog to integrate a layout. I then went back to coding the application. What I found was that I began to get more consumed with the output and how it looked rather than the fact that it worked. I found I was programming for shorter durations of time.

Eventually, I actually took a step back and got rid of the layout altogether so I could just focus on the code. I found that I would work longer and with less distraction since I had no design elements to worry about.

Know when to use the scaffold plugin

Immediately upon getting the database created, I set about running the Scaffold plugin for each table. The Scaffold plugin, which is a wonderful bit of code by Raul Riera, creates the model, view, and controller with CRUD functions for whatever db table you point it to. I thought this would be a quick way to get up and running so I could concentrate on the more complex code. It certainly got the application running very quickly, but I found that a lot of the generated code got in my way or caused distractions for me. This is not any kind of judgement of the plugin itself. Honestly it could just be me. Again, I took a step backward and began to code my models, views, and controllers from scratch by hand. Ironically, this step backward actually resulted in my pace picking up.

What’s next?

I have to admit I feel a tremendous sense of accomplishment at finishing any project and this one was no different even though it is simply a personal project that likely no one will use. I learned a lot about CFWheels during the course of building LitePost. I intend to tweak it with additional features and improvements. My hope is that by making the code public, others in the CFWheels community, the ColdFusion community, or both will take a look and offer up constructive criticism. I feel this is how I can learn to be a better programmer.

At the top of my list of things I’d like to do is add a rich text editor instead of the plain old textareas that are currently in use. I’d also like to come up with a better RSS feed. Currently the feed is done using the <cffeed> code straight from the CFWACK. The query is hard coded with no paramaters and the XML is generated at the end all on the same page. I’d like to do it using a controller and possibly a custom layout that is XML rather than HTML/CFML.

Previously, I took care of most of the set up for the LitePost blog application. The CFWheels core files are in place, the DB created, the Scaffold plugin installed and executed. I also downloaded the TechJunkie layout from styleshout.com for the look and feel. It’s time now to apply the layout to LitePost.

Inside the views/ folder is the layout.cfm which is the main layout for all my view files. This is where I will be making my revisions. Looking at the index.html file from the TechJunkie layout, I found where the body content begins and ends. The author of the layout conveniently commented the exact spot and wrapped it in <div> tags for me. Then, I copied and pasted everything above the <div id=”main”> into layout.cfm just above #contentForLayout#, while copying and pasting everything after the closing </div> after it. I then added <cfoutput> tags around everything.

Now I needed to take care of a few last steps to get TechJunkie fully integrated into LitePost. First, Icopied the entire contents of TechJunkie images/folder into the images/ of LitePost. Finally I added a stylesheet link tag just after the <title> tag in layout.cfm. CFWheels has a nice helper function to get this done. My code looks like this:

#stylesheetLinkTag("TechJunkie")#

CFWheels knows automatically to look in the stylesheets/ folder for stylesheets. Similarly, CFWheels already knows to look in the images/ folder for all the images I added from the layout earlier.

Thanks to CFWheels, I have spent more time writing this blog entry than I have coding so far. Next I’ll start coding the main blog page, the entry listing page, and individual entry display page.

Several months ago, the good folks at CFWheels ran a contest to create a version of LitePost using CFWheels. LitePost is a simple proof-of-concept ColdFusion blog application built using various CF frameworks. You can learn more at the LitePost project. Although the contest ended a long time ago, I decided I would build my own CFWheels port of LitePost as a way to get more familiar with the framework. This will be the first in a series of blog posts of the experience.

Getting started was pretty simple. I just downloaded the CFWheels framework files and drop them in a project folder under my local webroot. The I downloaded the LitePost database script and ran it on my local MySQL server. I also added the Scaffold plugin from the CFWheels plugins directory. 3 steps and I was ready to begin. But not so fast. I decided rather than code, to take a step back and think about how a blog should work. Sounds strange since I use a blog regularly. But that is precisely the point. I’ve used a blog before, but I’ve never coded a blog application. So I’m looking at this blog and how it works so I have a good idea about how things should work in my version of LitePost.

Things I’ve noticed:

Blog entries are public, everyone can see them.

Everyone can post comments on a blog entry

Logged in users can create, edit, and delete entries.

The blog main page contains the 5 latest entries with a link to the full list of entries.

The category links in a blog post links to a list of blog entries in that category

The author link leads to a list of entries by that author

I think I have a fairly good idea now how my blog should work and can begin coding. That brings me to my first coding task, and I didn’t write a single line of code to do it. I ran the Scaffold plugin on each of my DB tables to create my models, views, and controllers for my CRUD functions. That’s a lot of code generated automatically. Now I can concentrate on customizing the generated code to work similarly to my WordPress blog.

As a last step to getting started, I browsed the styleshout.com site for a suitable layout for my LitePost blog application. This is a collection of open source html templates you can download and customize for your own site. I chose the TechJunkie template for my blog. This template is designed for blogs and I like the color scheme and layout.

That’s it for the initial set up. In my next post, I will integrate the TechJunkie layout template into the CFWheels framework.

I have continued with the CFWheels screencast tutorials in building forms and handling form data. The focus today was on form validation. CFWheels has some really cool methods to handle the data after form submission. Using the validatesPresenceOf() in a model CFC, we can ensure required fields have been entered. Simply pass the required fields to the method and if there are errors, the hasErrors() method with evaluate to true and the save() method will not insert data to the DB. The just execute the render() method to get back to the form. Add a call to the errorMessagesFor() to the form view and a nice bulleted list of errors is displayed along with the form. The form fields with errors is now wrapped with <span class=”field-with-errors”> allowing us to use some CSS to make the errors stand out. All done with very minimal code. Coding this took maybe 10 minutes and about 30 total lines of code. In spaghetti code this would take me at least 30 minutes and would have been considerably more lines of code.

It’s late now, but what comes to mind is overriding the error messages that are generated automagically with messages that mean more to the user. So instead of saying, “ysnSubscribe is required,” the error message reads “You must choose one of the subscribe options.” I’m sure there’s a relatively simple way to do this but it’s late so it will have to wait until tomorrow. I will say, however that I am pleased so far with how simple some of the more routine coding tasks become with CFWheels.