About KCWebCore
KCWebCore(formerly KCMUG) is the new Adobe Users Group in Kansas City; managed by Dee Sadler. We are a community committed to skill enhancement, inspiration, and networking through the use of Adobe software and other Web-based technologies. We are the core of web design and development in the Kansas City area.

Frameworks Conference

Yours truly is speaking at the Frameworks conference in DC next year. As an Adobe instructor, this is exciting because I don't normally get to do a customized type class that combines standards, ideas, and programs all into one cool class. So, I'm speaking with my friend Dave Powell which is a Applications Specialist at the UNC School of Pharmacy in North Carolina.

Dave and I got to talking at the Summit Adobe had for us User Group managers last Summer in San Jose. We both were designers first, then started coding and more. Dave is a ColdFusion and Python person and, well you guys know all about me already. We hit it off right away, as I did with all the managers, and after a couple of drinks decided that the one thing missing at some conferences were a Design for Developers session. Luckily others agreed and suggested me for the conference, and voila, we are speaking. The goal was always CFUnited, but thought the Frameworks conference was a good place to start.

The details are below:

The Frameworks Conference is being held February 1st & 2nd, 2007 at the Bethesda North Marriott in Maryland! There are more details at http://www.frameworksconference.com/ Hope to see you there!

CFUNITED - Coldspring and AOP Made Simple

If you've been anywhere near a blog or even another CF developer lately, it's quite likely you've at least heard of Coldspring, and you may even be aware that it is a 'framework'. In an informative session entitled 'Inversion of Control and Coldfusion: Using Coldspring', speaker Dave Ross succeeded in conveying a good basic understanding of what Coldspring does and why you should consider it as part of your application's architecture.

CFCs objects have the very useful ability to utilize other CFC objects within themselves. For instance, I may have a USER object that handles all aspects of a user, and an EmailServices object that handles aspects of email for my application. By creating an instance of my EmailServices object inside of my User object, my user object can, internally, utilize whatever methods EmailServices provides. In order to accomplish this from a coding perspective, however, we essentially have to do one of the things that OO says we shouldn't: hard code the relationship. This is the niche Coldspring fills.

Coldspring is a framework that is essentially an object factory. If you're using Coldspring, then whenever your app needs an object it asks Coldspring to instantiate it rather than the code instantiating it itself. In our previous example, rather than have our User object creating an instance of EmailService, Coldspring has already been informed via an XML file that whenever we ask for a User object it should ALSo include an instance of the EmailService object within it. Coldspring has just allowed us to keep our components decoupled, and this is a very good thing. Now, if my EmailService changes the way it is instantiated, I don't need to go into every other component that utilizes it and alter the instantiation code. Since Coldspring will be the one creating the EmailServices object, it will deal with those changes alone. By passing the control of object creation to our Coldspring factory we have implemented the buzzword mentioned in this session's title: Inversion of Control.

Dependency Injection is another buzz phrase associated with this topic, and essentially refers to the scenario where one object is depending on another (our User object depends on our EmailServices object), and the fact that Coldspring is 'injecting' an instance of the EmailServices object into our User object...Dependency Injection. There are two types of dependency injection, each one differing only in the way that the User object internally refers to the EmailServices object. The first type, called "Constructor-Argument injection", means that the EmailServices object will be passed in via the constructor of the User CFC, in the init method. The second type of injection is called "Setter Injection". With this one, rather than passing in the EmailServices object during instantiation, we're simply going to "set" it as a variable within one of the User object's methods. Here's why two methods even bother co-existing: circular dependency.

Circular dependency is another way of saying that object 1 uses an instance of object 2, and object 2 uses an instance of object 1. If you tried to use Constructor-Argument injection, CF would not allow you to have this circular dependency. By using Setter Injection, however, you can.

Lastly, Dave Ross elaborated on another facet of Coldspring called Aspect Oriented Programming, or AOP. In a nutshell, AOP is what allows you to take one method from a given component, let's say the LogIt method from the LOG.CFC, and cause that method to be executed at various times and places throughout your application. As an example, let's say that you wish to log every action executed against a user record, as well as when logging in or logging out of the application. Old-School style, you'd have to go to each of those methods and add a line to perform the logging. Ah, but with the beauty of Coldspring and AOP, you simply set up logging within the XML configuration file that already defines the relationship between CFCs, adding a few more definitions telling Coldspring to execute the logging before, during, or after the execution of other CFC's methods. Niiiice.

Setting up Coldspring is not or the faint of heart or those who are convenience enthusiasts, but if you will take the time to learn and implement it, you'll find yourself a better programmer for it.

CFUNITED - MVC Unraveled

I spent the first hour of my morning listening (and gladly so) to Joe Reinhart preaching the need for us all to focus on just comprehending exactly what MVC is. Personally I felt like he started the presentation a few feet over most of the audience's head, using terms that were quite comfortable for him but new to many of us. Not his fault, and to his credit he did take the time to define many of the terms for us. Despite the elevated theme, in our short one hour together he accomplished his task in a two-fold manner: by increasing the audience's vocabulary, and by creating a sample app that used the MVC pattern.

That's right, MVC (Model View Controller) IS an application design pattern used across the board with any object oriented language. It also happens to popularly be known as the king of patterns, itself being an efficient symbiotic relationship between three other patterns of lesser scope and with more focused purpose. The Strategy pattern, Observer pattern, and the Composition pattern are what allow MVC to do what it does so well: keep our application segregated (loosely coupled) while allowing each portion of the app to remain highly specialized and autonomous (encapsulated).

The M in MVC is the Model. This is the portion of the application where nearly (if not all) of the business logic and database access will live. Business rules, queries, special validation...basically, if it has nothing to do with the user interface, then more than likely it will live in the Model. Physically the model will be a collection of CFCs that contain the functionality mentioned previously.

The View is that portion of your app responsible for displaying and gathering data. It knows nothing about the Model, the database, the backend system...it only knows that it will display the data given to it, and it will deliver the data it collects. Physically the View will consist of CFM templates containing primarily just layout information, such as forms, tables, and CSS.

lastly we have the Controller. It's job within the MVC design pattern is nothing more than passing data back and forth between the Model and the View; that's it.

The last 10 minutes (that's right, 10 minutes) of the presentation were spent building an entire basic blog application from scratch. Using the Model-Glue Unity framework and some Eclipse Ant scripts, he quickly was able to add in all of the CRUD (Create, Read, Update, Delete) functionality for blog entries and comments. How was this possible? By leveraging the many hours of hard work that have gone into producing and uniting three frameworks that have been all the buzz lately: Coldspring, Reactor, and Model-Glue. By strategically editing XML configuration files and using such shortcuts as "scaffolding", it is possible to auto-generate what would otherwise take a person days to code by hand.

Witnessing the creation of an entire application in just a few minutes is both exciting and disconcerting. On the one hand, Model-Glue Unity provides the developer with shortcuts that are nothing short of amazing, allowing productivity levels that I believe are unachievable otherwise. On the other hand, I could very well empathisize with the framework opposition camp, seeing how it is they could say that the usage of advanced frameworks such as Model-Glue will lead to the de-evolution of the CF community, removing many of the "needs" that often motivate developers to learn and grow. My own opinion, however, is that although frameworks such as this will allow us developers to become more productive, the convenience of it all will never quench the insatiable curiosity that has driven us up to this point, and we will always be "peeking under the hood" regardless of how much automation we adopt.

CFUNITED - The Framework Debate Continues

Most of you may be aware of the debate over frameworks that has been raging off and on since at least CFObjective back in March of this year. In the one corner, representing all that is opposed to the preaching of frameworks to the masses is Simon Horwith. In the other corner, representing framework evangelists and followers from all over the globe is Hal Helms.

I first became aware of this schism at CFObjective when I attended a seminar by Simon Horwith entitled 'Object Think'. It would more appropriately have been entitled 'Friends don't let Friends use Frameworks', as he openly bashed everything else that conference was about and made himself the public prosecutor of the majority of the CF expert community's opinion on frameworks. Last night was no different, as I sat in on a session here at CFUNITED entitled 'Celebrity Death Match'.

It was an open and formal debate between Simon Horwith and Hal Helms, who himself participated remotely via Breeze. The conference room was filled to the hilt as newbie and seasoned alike gathered to be judge and jury for the topic at hand. Let me summarize for you the two opposing arguments, and then tell you what the verdict was.

The Framework Opposition says that frameworks are a crutch that essentially stifle and hinder a developer's professional and technical growth. This camp says that if a developer begins his or her career using an open-source community developed framework, they will remain handicapped and incapable of ever being able to truly build an application from the ground up on their own, resulting in a pool of 'talentless talent'.

The Framework Supporters maintain that using a framework, though it is indeed a greater initial investment of time and resources, is a ONE time cost that is greatly offset by the long term benefits afforded at every level. The use of frameworks creates a community-accepted standard that takes an already robust common vocabulary to an exponential level, not only enhancing our ability to transfer and share knowledge on a large scale, but also to easily exchange entire applications and code without the need for significant investments of time to utilize. They also counter that in NO way does the usage of frameworks stifle a developer's technical growth, citing the fact that none of their own growth was stunted when they started using Model-Glue and the like.

Near the end of this mock trial, Simon made a point that set me free of the conflict of the debate. He related an account of a project he had worked on in England some time in the past in which he had 100 developers under him. He shared how it was that this large team had tried using Mach II, tried using Fusebox, and in both instances found those frameworks wanting. Then he showed them his own 'methodology', which they readily adopted and used to successfully complete the project. Simon's point was that he and his team had accomplished a large task, and didn't need to use a framework in the process. But between Simon's words lay the whole truth of this matter, the truth that finally freed me from the points and counterpoints that were tugging my intellect in both directions. This truth, folks, is this: Any application that actually works uses a framework. Simon likes to call his framework his 'methodology', resisting the urge to give it any kind of formal name or documentation, and thus disguising it in obscurity and vagueness. Nevertheless, it is indeed a framework. So folks, this whole debate is bogus, the opposition's stance is vapor, and in reality is a one sided debate with the answer to the question of the validity of frameworks already woven into the very fabric of both sides of the argument. The answer, my fellow CF coders, to the question of whether or not using frameworks is a good thing, is an unequivocable "YES". You need frameworks, and whether you roll your own or adopt a community standard, there is no way to avoid them...logic will not permit it.

After being set free by this epiphany, I then had to wonder at what it is that truly motivated Simon Horwith to take such a public stance. What moved him to place himself in the limelight and accept the label of 'framework-hater'? Is he plain and simply a rebel, one who will swim against the current on principle alone despite the direction it takes him? Or, more than likely, is it that he is simply a self-appointed sentinal of the free thinking world, fearing the loss of innovation and open-mindedness and the onset of apathy and weakness in the CF community's skill set? Finding nobody else who could see what he saw, did he then, in our defense, take up the cause to protect what it is he cherishes and believed to be utterly at stake, giving his all to "keep balance in the Force"? We are the jury here....

Back in the conference room the smell of popcorn and cotton candy filled the air as the debate was brought to an end. The judges called for final comments and then a show of hands from the "jury" as to who had won this debate. Almost unanimously, the jury sided with Hal.

Bottom line folks: ignore this debate and give the hard work of your more advanced and experienced peers the attention it is most worthy of. Must you choose a religion (framework)? No. Choose them all, choose one, choose none and roll your own; it doesn't matter. It's all good, it's all good. what IS important is that you keep striving to learn, always push yourself to new levels of understanding, and then you, like ALL those in both corners who are so zealous for their CF causes here, are right.

BlogCFC was created by Raymond Camden.  © Copyright 2006 KCWebCore. Some Rights Reserved.