It's been said more than a few times that one should be careful when applying design patterns by blindly copying example code. Sean has even gone so far as to remove the example code from the Mach-II design guide to deter that practice. Blindly copying code is definitely a bad idea but frankly a lot of folks find books like the "Gang of Four" book to be hard to digest. So when I was browsing Amazon, I found it interesting to come across a book called "Learning Design Patterns by Looking at Code". Since a lot of programmers learn by looking at code, rather than an academic approach the book takes the approach of showing how patterns are used in real world applications. I have yet to read it but I'll post a follow up after I do.

I posted to CFCDev asking if anyone had read it. Noone had but it spurred quite a few other recommendations. I've added "Learning design patterns" and some of the other recommendations to the Mach-II.info book shelf.

If you've ever had to access a common function library from your views, you're probably using a plugin to create reference to the functions in the properties then injecting the functions into the event object on pre-event. This is discussed in the FAQs.

With v1.0.10, things are a bit more convenient. Most people know that the Plugin, Listeners and Filters extend the new BaseComponent so you can access properties from within those components with getProperty() and setProperty(). What most people haven't noticed is that although the ViewContext doesn't extend BaseComponent, it has its own getProperty() and setProperty() methods. So, if you've set your function library as a property called "functionLib", then you can simply refer to it from a view by

<cfset fl = getProperty("functionLib")/>

and you can skip the pre-event.

There was a question on the Mach-II list today asking about how to access properties from Listeners in light of the changes made for v1.0.10. The answer is that Listeners inherit getProperty() and setProperty() from the new BaseComponent that was added to the framework. This is apparent if you refer to the online documentation.

However, online documentation is not the convenient when you're, well,offline. Also, you have to leave your IDE which not optimal if you're cranking out some code and really in a groove. Wouldn't it be great if the CFC docs where available in your IDE?

Well, I have done just that. I have generated help files of the Mach-II CFC documentation for HTML Help format (aka .CHM), CFStudio/Homesite and Eclipse/He3. Download it from here and let me know what you think.

First, if you develop in Mach-II and your not on CFCDev, what are you thinking? Go subscribe. Now. Ok, with that out of the way we can continue...

The other day, Nando posted an excellent question to CFCDev inquiring about validation techniques. Specifically, he was asking if people implemented validation on setter methods of business objects. Barney responded and he described two schools of thought: 1) a business object is never invalid and therefore validation is done in the setters and 2) a business object can be invalid but can't be committed to the database until it passes validation. He also made the point that you should enforce business validation in your business objects but not input validation. However, he went on to make the statement that using unique keys on a database table to guarantee uniqueness was a "horrible option". Now, if you've looked at the Mach-II sample application you'll notice I use this exact technique to guarantee unique usernames. It didn't seem like such a bad idea to me (or Sean) so I asked Barney to provide clarification. He went into great detail about how he does validation in his applications. All very good stuff. However, I still couldn't fathom how his implementation was going to guarantee uniqueness. As we drilled down on it, he conceded that unique keys are the only robust method to guarantee uniqueness. Good. I'm glad we got that cleared up.

Anyway, the thread is a good read. It really makes you think about how you do things and why.

Originally blogged by Doug Hughes, there is a bug in Mach-II v1.0.10 where the configure methods of plugins are not executed in the order the plugins are declared. According to Sean, PluginManager.configure() should look like this: