object programming coldfusion

I just spend about 3 hrs trying to figure out where a piece of output was coming from. This is a bit of a rant against object oriented programming, at least in CF. First off, the resome i was looking for this piece of code is to analyze a program area in the application. For some users, who have alot of data, this list that is build and displayed to the user takes way too long to build. Sometimes in excess of 60 seconds. I think it has caused us to change the loop time out setting in the administrator.

This application is build in a framework called machii. Machii is capable enough framework, a bit heavy, meaning a lot of overhead and files that comprise the framework. Machii makes it easy enought to know where to begin looking for the problem. Follow the event, look for listeners that are calling into a service layer of some sort - follow the service layer into a gateway or DAO object - throw in another framework, coldSpring, and you can get pretty confused pretty fast. Thats a different story.

I traced down into the machii event and found the listener calls and the view files that appeared to be responsible for outputting this slowly developing content. The view files did not have much content in it - just a mysterious call to an XML function. My investigation then took me in another direction, until i found where the content was getting gathered, not displayed. The output is stored in a group of Objects and then xmlized by another function. Hmmmmm, is there a really compelling reason why this content was not simply being returned as a query object? Light, easy... But not object pure. I think this may be a case of the developer being a bit of a OOP purist and treating CF like Java. And why are we xmling the result? What is the gain here? More overhead and complexity. Perhaps its a case of "we may need this later in this portable format"...rather than YAGNI or KISS. Anyway, this feels like alot of overcooking to me. It took me way too long to find this class that was extending a base view event class - to just find about 15 lines of code responsible for actually outputting content.

Bottom line - private functions in cfcs should not be outputting anything. Let the cfcs do their job of getting data and making decisions about what to do - leave the view files to outputting the results.

OOP is good, in the right places, but not always in every situation.