ModelGlue 3 first impressions from an MG newbie

For the last 5 weeks, I’ve been working on a proof-of-concept application for a client using ModelGlue Gesture. This was my first “real” experience with ModelGlue. My only other exposure to ModelGlue came from watching a Breeze (as it was called then) session from Joe Rinehart where he built an entire blogging application in 7 minutes (or some equally ridiculously short amount of time). At the time, frameworks and design patterns hadn’t “clicked” with me and I struggled mightily trying to understand the concepts of what was going on under the hood. Needless to say, I didn’t pursue ModelGlue for very long due to my lack of understanding and the usual pressing project schedules.

Since that time, I’ve had the opportunity to get some formal training in MVC frameworks (specifically MachII) and have built a few applications using MachII. Along the way, the reasons for using an MVC design pattern have become much clearer and I’m now comfortable thinking about applications in the respective tiers that MVC frameworks encourage you to develop with. Having all my MVC experience in MachII up to now, I was really excited to have the chance to build an application in ModelGlue, and be able to work alongside Dan Wilson as we built it. It’s not often that you get the chance to learn a technology by working with one of the folks primarily responsible for the technology.

Read More

What I’ve Learned: MVC frameworks are worth it

Most of us that have been around programming for a while have heard the arguments for separating content and layout in our applications numerous times. Likewise, most of us have nodded our heads and generally acknowledged that it’s a “good idea” or something similar. Over the last few days, it’s really hit home for me why this is such a good idea.

Two of the projects I’m working on at the moment have had complete user interface updates in the last two weeks. One is a MachII project I’m working on with my brother. The other is a ModelGlue project I’m working on with another client. In each instance, the decision was made that the template that we were using just wasn’t flexible enough to allow us to easily do what we wanted to so the decision was made to replace it. I’m not talking about a simple color scheme change–both these were radical template changes that changed overall layout containers and content containers as well as the styles for the content elements themselves.

In a traditional, “spaghetti” ColdFusion site like we all wrote back in the early days (what I like to call the “Bad Ole Days”), this would have been a nightmare to do on a site of any size. Granted, these two applications were both small- to mid-sized at the moment, but the amount of work and testing required would still have been significant.

Here’s the real kicker though. Each of these were done in less than 1 man day’s worth of effort due to the way MachII and ModelGlue separate the different parts of the process of generating the final HTML page! That’s just awesome as far as I’m concerned!

So, for those people that use the argument that MVC frameworks are more work than they’re worth except in large, enterprise-class applications, I submit that the first time you encounter this situation, you just might change your mind.

*Disclaimer: I know that there are other MVC frameworks out there for ColdFusion and they solve a lot of the same problems that MachII and ModelGlue do. I only mention these two here because they’re the ones that I worked with directly.

Configure FusionDebug 3 Beta for use with Railo 3.1 on Tomcat

For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup. Until tonight that is.

I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.

Read More

Standardizing HTML forms with the cfUniForm custom tag library

As web developers one of the most frequent things we’re tasked with building is some sort of form to capture data from our visitors. As we’ve all learned (some of us the hard way), putting a form out there and trusting that our visitors will use it exactly the way we design it every time is the proverbial pipe dream. How many times have each of us written Javascript functions to validate the entries into form fields? It’s much the same every time and, honestly, it gets old reinventing the wheel each time. Enter cfUniform, a very robust, open-source custom tag library from Matt Quackenbush (with others contributing).

cfUniform is a ColdFusion custom tag library that makes adding validation to your forms a snap. The fact that it writes (most) validation for you based on attributes you put in the tag makes it worth using for that feature alone in my mind. However, the benefits don’t stop with validation. It also styles your form fields, labels, hints and error messages for you. Since you can configure a link to a CSS stylesheet in the configuration for the custom tag, you can skin the output generated by cfUniform to match your site’s look and feel.

Read More

Making configuration even easier with ColdSpring’s hidden gems

In my last post, we went through a brief introduction of ColdSpring and how you can use it to make configuring your application’s objects much easier. We discussed how objects (beans) are declared in ColdSpring’s XML configuration file and how you can pass any number of values into ColdSpring to be used in configuring those beans using the defaultProperties argument when you create the ColdSpring obect. At the end of the post, we touched on a slight “problem” with using ColdSpring this way.

To be fair, the “problem” isn’t with ColdSpring at all. The problem is with us developers–we’re lazy and we hate redundant typing. In a large application with dozens or more objects, we don’t want to constantly have to type ${dsn} every time we want to inject the DSN property into a bean. Multiply dozens of objects by potentially several properties needed by each object and you can set yourself up for quite a bit of typing, just to get the beans configured (and that doesn’t even take into account that most of us are bad typists and can’t spell DSN the same way a dozen times in a row).

Read More