So a week or so ago I published a new version of the framework core with a minor enhancement to improve on the workaround for web-services/onRequest that may resolve the current issues with running the framework on BlueDragon/Railo. At the time I didn't realize that I had introduced a new bug (albeit small) that prevented the onMissingMethod() feature from working, so any page request would require the base template in addition to the process code in the /_tap/ directory. This is true for ColdFusion 7 anyway, but on CF8 you're supposed to be able to omit the base template and let the server automate it (except for index.cfm).

Anyway in the process of working on some integration for a project for Eric Jones, I discovered this bug as well as a couple of other minor bugs in the Members onTap plugin that were introduced since the recent upgrades for new DataFaucet features. The member plugin bugs only occurred if an administrator attempted to edit their own account via the admin area (instead of the member area). Admins aren't supposed to be able to edit their own roles (because they can't add roles they don't already have themselves and shouldn't be allowed to de-permission themselves), so there's no really powerful reason for an admin to use the admin area to edit their own profile anyway. But it ought to work, so I've fixed those bugs as well... one of which resulted in the admin de-permissioning themselves when they saved the form. D'oh! ;)

Also the integration for Jonese's project is going pretty darned well! I've been able to bypass the IoC for the member plugin to introduce a custom member object which extends the default member object and adds a 2nd table with some additional profile information to the member objects for this project. That in itself is something I'm rather happy with because of how seamless it is. :) I'll be posting more blogs later with additional details about how the integration is done, as well as more information about the project itself as an example of the onTap framework and DataFaucet in the wild. ;)

On a more personal note, I honestly don't think that "who's using this framework?" is ever really a good question to ask. I mean... it's not that asking it is a bad thing, but rather that it's simply unhelpful and especially using it to make decisions can be counter-productive. And I'll share briefly the reason why I feel this way.

The Fusebox framework has been around for a good long while now and there are a variety of mixed feelings about it in the community from the die-hard Fusebox enthusiast to the extreme opposite end of people who really just can't stand it. Each of them has their reasons... but what I'm really getting at here is that Fusebox projects are much the same way. I've never been a big fan of Fusebox myself, otherwise I wouldn't have created the onTap framework. ;) But despite my own preferences I'm reasonable enough to acknowledge that of the large number of Fusebox applications there are in the wild, some of them are well made and some of them are poorly made. Whether a given Fusebox application is good or bad depends to a much greater extent on who managed the project and what resources they had available than it does on the fact that they used Fusebox as their foundation.

I expect the same will be true of just about any framework. There are going to be good and bad Model-Glue apps and good and bad ColdBox apps and I'm sure there will be good and bad onTap framework apps. The fact that the framework isn't being used at Wells-Fargo or on the website for the Metropolitan Opera says absolutely NOTHING about the quality of the framework. The only thing it says is that I've done a poor job of marketing it thus far so it hasn't gained traction (and this is shown to be the case in our frameworks survey also, which I'll talk more about later).

That's the larger reason why I'm now focusing a lot of my time and energy toward being more vocal in the community and improving the marketing. And looking for an evangelist to take the reigns some in the marketing department. :)

There's been a lot of talk today about Adobe's release of the new Bolt IDE for ColdFusion.

hmmm... y'know, this movie's due out any day now...

Coincidence? ;)

Just thought I'd post a brief note to mention that I'm happy to see the downloads for version 3.2 of the framework hit 800 today. Although that may not sound like a huge number, remember that the onTap framework has been on RIAForge for less than a year. That means that in the 11 months since mid-december of last year, there have been an average of about 2.5 downloads per day! That's pretty darned good! Particularly when you consider the rather large amount of time and effort it takes to get buy-in into any technology. :)

I'm still working on the first release of the onTopic forum. It's taking me a little while not because of the objects, but because of the user interface / interaction aspects. The idea behind this forum system does require a slightly different business/object model than a typical web forum, however, the big challenge really is in accomplishing the interface I wanted. It's actually somewhat Twitter-esque in its approach, but I'll let you see that when it's released. ;) If you're interested in a sneak peek of course you can always fetch it from the Subversion repository for the onTopic project.

Also, still hoping to get more participation in this frameworks survey. What helps you get things done and be the best at your job? We want to know! Knowing that will help us build better tools for you! :)

Hey, just a brief note to let everyone know that Brian and Adam have released episode 21 of the CFConversations podcast which was an interview with Yours Trully. I've never met Mr. Trully in person, but I hear good things! :) The interview covers some technical subjects including both of the frameworks I've developed, DataFaucet and the onTap framework although we also talked a bit about my comic strips and about living and working with autism.

When people look at my code I get a wide range of responses from incredulous to dismissive to excited. I imagine it's not much different for most advanced developers. As I imagine is the case with many skills, although the expert certainly knows more than the novice, experts often disagree. Why? Well because experts "know better".

A novice looks at a piece of code and generally speaking they can't really tell the difference between code that's "elegant" and code that in spite of "getting the job done" will become problematic later. It's the same with a piece of sheet music or an architectural blueprint or whatever... any skill you haven't thoroughly developed leaves you with a knowledge gap where you can't really discern the subtle differences between good and not so good work. And although gaining skill allows you to become more discerning, it often leads to some rather wide disparities of opinion about what constitutes good or not so good work.

In the past week or two the CF community blog-o-sphere has been talking about what it means to be OO or what it means to be good OO or to "simulate OO". Ben Nadel expressed some frustrations about reading articles about accessors and mutators. We've heard more of the tired, old and completely invalid arguments about ColdFusion not being a "true" OO language because of things like the lack of abstract classes or the fact that a CF object isn't equally as efficient as a Java object (which lacks a lot of the behavior of a CF object). And of course just today Pete Bell and Brian Rinaldi published a short debate about the use of OO techniques.

I'm not going to address the notion that we're "simulating OO" instead of writing OO code when we work in ColdFusion, because frankly, those arguments are stupid, based on misconceptions of OO and not worthy of your time. 'Nuff said.

But in bringing up the previous blog posts, what I'd like to point out is that I think quite often we ask this question: "is this OO?" We may ask it in various different ways. Is this a good OO technique? Is this the way OO applications are written? etc. But the basic question is the same. Is this OO? Or is it "OO enough"?

And I'm going to make the claim that this question, however it's phrased, "is this OO", is not only completely useless, but it's actually counter-productive.

It's seductive, that's for sure... Because it's a very simple question, and as humans we like simple. Even programmers as much as we like complexity still gravitate toward simple things. Sometimes we call them "elegant". The problem with "is this OO?" is that it's far too simple. It makes the rather bold assumption that either the questioner or the person asked has some magical definition of what "OO" is... or worse of what "good OO" is. We don't.

Part of the problem is that the definition of OO is pretty well known and yet especially in the ColdFusion community its nearly impossible to get people to stop attributing new extra requirements on the definition of OO. Witness comments about ColdFusion not being OO because it doesn't have abstract classes, or previously because it didn't have interfaces. Neither of those two things make it a "procedural language".

I've seen this apply to experts as well as novices. Several years ago I saw some notes from a conference presentation in which Jeff Peters (a member of Team Fusebox) talked about various frameworks. He was kind enough to mention the onTap framework and yet in spite of the fact that it already included a small library of CFCs and a variety of tools to help manage them (including workarounds for the lack of application-specific mappings), described it as "a procedural approach". This was shortly after the initial release of Mach-II and at the time as best I could tell, his reason for judging the onTap framework as "a procedural approach", centered around the fact that it didn't have a config dialect in XML! Which of course has zero to do with what is or isn't OO, as has been made abundantly clear in the intervening years and recent releases of Fusebox and ColdBox.

I mention Jeff Peters here by name not to "call him out" but rather merely to point out the fact that being an expert doesn't make someone immune to poor judgment. I consider Jeff to be both skilled and knowledgeable. That doesn't change the fact that we're all still human and that means we're all still subject to just that kind of biased assessment.

So right up front, asking "is this OO" is very likely to lead to people giving the answer "no", when the correct answer is "yes" because they've bogusly attributed some new property as a requirement for the definition of OO.

At this point the question "is this OO" becomes one of a religious nature, not of a technical nature. Because each individual's definition of what is or isn't OO depends so heavily on their own personal interpretation of the literature. And because so many people will simply look for excuses to claim that something is "not OO" just because they enjoy shooting things down. We may as well ask "what would Jesus do?" ... I need to persist my data in a database ... well Jesus obviously would use an ORM... a Divine, OO ORM tool, written in Java!

Sorry... that's a useless answer... it's a useless answer because it's a useless question.

So if "is this OO?" isn't a useful question, then what is?

Questions that are useful:

1. Is this highly cohesive?
1. How many things does this function/method do?

   if this function or method handles both user authentication and changing a user's password, then DING DING DING raise the red flags, it's not cohesive

2. How many things does this object do?

   I don't have any hard and fast rules for this one - sorry

2. Is this well encapsulated?
1. How many *other* files would I need to change if I were to change the behavior of this function or method?

   the ideal answer here is zero, that's what you should strive for - one or two or even three may be okay... FOURTEEN (as was the case on one of my recent jobs) is a disgrace and you should hang your head in shame

2. How easy would it be to extend this CFC to change its behavior to do something else? How many functions/methods would I need to overwrite to accomplish that task?

   again, I don't have any hard and fast rules here, but it's a useful question

Stop yourself when you're about to ask "is this OO" and ask yourself these questions a few times instead. What you may be surprised to discover is that asking yourself about the specific goals of OOP like cohesion and encapsulation may result in different answers than asking "is this OO?" You may find that things for which you would normally answer "yes, this is OO" turn out to be very poor examples of meeting these goals. Or vice versa, that things for which you might normally nay-say and say "no, that's not OO" actually meet the goals of OOP quite well.

So that's it for today... I realize this has been something of a rant on my part. ;) But I hope that some of you find this article useful. And if you have any suggestions of other useful questions to ask, please do share them. :)

It's not quite a Halloween edition... I happened to do the editing on Halloween. :)

I found a better workaround for the web-service/onRequest() problem. This should allow the new build to work on Railo and BlueDragon although I don't have either of them installed, so I haven't tested them yet.

So rather than wait around for someone to pass a Fusebox application my way, I realized that there actually was still an old FB3 sample application (all of one fuseaction) available for download from the fusebox site. So I grabbed that code, combined it with the necessary bits from a traditional FB5.5 skeleton and have created an upgrade path from FB3 to FB5.5. You can download the code below.

It actually wasn't tragically difficult to implement this. I know a number of folks seem to have been under the impression that this would be a big challenge. It turns out that there's a relatively convenient and simple way to implement this. There are a couple of things that contributed to this being possible (or at least easier). One is that the skeletons for these versions don't share any files. FB3 didn't have an Application.cfc and FB5 doesn't need an index.cfm, that was handy. Secondly if FB5 fails to find an event, it throws a convenient "fusebox.undefinedFuseaction" error that can be trapped and used as an entry point to run the FB3 app. Because FB3 runs entirely within the unused index.cfm, it's easy at that point to fail over to FB3.

There are of course limitations. You can't <do> an FB3 fuseaction from within an FB5 event for example. The point here was not to create a total mesh of the two environments, but rather to create a discrete way to support legacy code while continuing with future development on the newer versions of Fusebox. Personally I think this achieves that goal rather nicely. :)

For anyone interested in the code, the download is in the menu below (between the comments link and del.icio.us). The included release notes will tell you everything you need to know to get it running. Hopefully this will find its way into the 5.5.2 release of the Fusebox core. :)

Hi all!

I've got what I think is a fairly simple request. I'd like to see if anyone's got a fairly simple app written in Fusebox 3 that they could point me to either open-source or that they'd be willing to let me use for some testing. The reason I ask is that I was just sitting here thinking about frameworks in general and I know that there's been some contention over backward compatibility in the Fusebox community for a while.

Right now it's looking like the "minority" of people with applications still on Fusebox 3 don't really have a great upgrade path. They can spend a lot of time rewriting code, they can stick with FB3 indefinitely or they can let their FB3 apps "rust in place" while they work on new projects in a more recent version.

Of course, Fusebox 5.5 is now mostly backward compatible to Fusebox 4.1, which is pretty nice for those who did upgrade to 4.1. But backward compatibility to 3 seems to be a bigger hurdle, one that Sean Corfield had challenged himself with when he was heading up the project, but that it looks like Adam might be less interested in following up on. Adam's a great guy, but he's also got a lot of stuff on his plate and the general perception is that the folks who still have a lot of code in FB3 are kind of a minority.

I wouldn't even be asking this myself except that I had a sudden inspiration. I think I may be able to produce a fairly elegant way of merging them in such a way that those of you who still do have FB3 apps can maintain the existing code in your applications while writing new code to Fusebox 5.5. Anyway, if you're one of those folks who's got some FB3 code and you'd like to have a better upgrade path let me know. :)

Thanks!

Oops! It looks like when I made some recent changes to the member management plugin to take advantage of some of the new features in DataFaucet, I somehow accidentally got the addManyToManyRelationship() call into the member.cfc twice. Which in my case caused an error when I tried to install with a clean database. I guess I also neglected to test the installation into a fresh database, so that's my bad... There should probably be mxUnit or some other testing framework for these things, but TDD has been on my growing "when I have time" list for a while. In any event it was easy enough to fix, so I fixed it and uploaded a new build both to RIAForge and to the web service. So if you've been unable to install the Members onTap plugin recently, you can follow these steps to download the new build and try the installation again.

1. open up your plugin manager (http://[ontap]/admin/plugins)
2. select the "more" tab
3. hit "search"
4. find the Members onTap plugin in the list and hit "install"

Maybe I'm taking this too literally... as often happens with people who have Asperger Syndrome. Anyway, the other day someone posted a comment on Dan Vega's blog about CF and OO. Here's the comment:

I will feel more comfortable calling CF OOP once it's not as tag based. Once i can create and extend some of the built in tags. When i don't have to put on my page i could simply write a component that can create an instance of the cfform and append other objects and then call a construtor method on the CFform Object to display it on the page. Cough cough ".NET"

I hope i don't get called a MS fanboy!

-- Aaron

I have mixed emotions about this comment. On the one hand, sure it might be nice to be able to extend some of CF's built in tags to improve the existing functionality? On the other hand, it's almost never really necessary... Aside from the ability to create all manner of "wrappers" for CF's native features (which I've done a lot of over the years), you can certainly use Java reflection for anything that can't be done with the native CF tags. And for that matter, the Java Loader makes doing that even easier.

But then why even bother with CFForm as an example? In my mind CFForm is kind of a quick way to get things done if a) you're new to CF and don't have a better form framework handy or b) if you're trying to do something for yourself quickly and quality isn't a concern. For that matter there are a bunch of open source or alternative form frameworks around. Aside from the form tools in the onTap framework, cfUniForm and coreForms both on RIAForge, New Zealand native and a good friend of mine, Matt Walker produces one called TerraForm.

Around the time that Flash forms and XForms were introduced in ColdFusion, Matt and I were talking about his project, wondering if the new features in ColdFusion would make TerraForm obsolete. It did not. And these days the general recommendation for Flash forms even is "use Flash" or build them in Flex. For that matter, the form tools in the onTap framework as well are still far more powerful than CFForm (and no harder to use). To be honest, the XForms implementation did inspire some new features, but it's still no replacement for the onTap framework's templating engine, (which imo frequently resembles that "code behind" concept you see in some of the newer MS technologies that Aaron mentioned).

But what tends to stick in my craw about these kinds of comments is the insinuation that the SYNTAX of the language has anything at all to do with its being or not being OO. So cfform is tag based? So what?! There are better form tools available anyway. But for that matter, even with the currently available features in ColdFusion 8, you can still implement CFForm in CFScript. Yes! Yes you can!

How does this look as a simple starting point?

Now I'm not going to be using this code myself, largely because I already have a set of form tools that are far more flexible already. This does however show that you can indeed even work with cfform in script. For the full code, you should see a download in the links below.

Brian and Adam have published the 2nd episode of the controller frameworks round-tables. I haven't listened yet, but I'm about to. :)