I ran into a situation this week while working on a MachII project I’m doing with my brother that I’m sure many of you have encountered before. We have our view pages broken up into small chunks that we render inside a “pod-like” layout on the screen. Many of these view pages are using a one or more jQuery plugins (including cfUniform, DataTables and FancyBox) which need the main jQuery library to be included in the header to make them work correctly. We had been doing something like this in the top of each view that needed jQuery:
1
2
3
4
5
6
| <cfsavecontent variable="jQueryInit">
<script type="text/javascript" language="javascript"
src="/javascript/jquery-1.3.2.min.js"></script>
</cfsavecontent>
<cfhtmlhead text="#jQueryInit#" /> |
This worked perfectly fine for a while, right up until the point where we had two views in the same request that needed jQuery. If you put the above code in each of the view pages, then only some of your jQuery plugins work because the jQuery javascript file was getting loaded and instantiated multiple times–wiping out everything that had been configured previously.
Read more…
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.
You ever had one of those ‘light-bulb’ moments? I love when those come along because it usually means that something ‘clicks’ that I’ve been noodling on. Today was one of those days.
The last 3 weeks, I have been working on converting a small content management application from ’spaghetti code’ to a Mach II application. The things that I’ve learned just in that endeavor are amazing. As pretty much any developer will tell you, there’s always a way that something could have been done “better”. But I’ve decided that I really don’t want to build any more applications without some sort of framework.
One of the concepts I’ve been interested in lately is the concept of using a service layer in your application. The idea sounds great and reasonable on paper, but I’ve found it hard to figure out exactly how best to do that when coding–until now. The concept really clicked home with me when I began creating a *very* small Flex application for one of the more intricate CRUD functions in the aforementioned application. I figured out that I had been thinking of the service layer at the wrong point in the “stack”. For some reason I had in my head that your service layer was actually one step higher in your application stack than your controllers. Obviously that’s not the case as I found out when I started trying to figure out how to leverage the code I had written for the Mach II app to be reused for the Flex app.
Anyway, the lightbulb went off and it dawned on me that my Mach II controllers should be talking to the service layer AND the controller functions in my Flex app could talk to the same service components without worrying about issues arising from framework specific code (as they would the way I have things coded now).
Now I have to go back and do a bit of refactoring, but even that will be easier because the application is now built with Mach II. At least I learned something this week…
