I stumbled across an honest account by Marc Funaro about how OO almost destroyed his business. He spares no detail in the post, but I still think it is worthwhile to read in its entirety as a reality check for yourself.
Dynamic languages like PHP and CFML have been on a quest over the past few years to be more "Java-like," adding more object oriented capabilities. These features bring a lot of promise for your code to become self-documenting and organized. But there have been undercurrents by pragmatists who contest that these features add unnecessary complexity for languages that were "fine just the way they were."
As I've progressed through my career with ColdFusion, I've started agreeing more with the pragmatists. While ColdFusion experts have been arguing about "XML versus no-XML" over the past year, I've strongly desired getting my work done so I could feel some accomplishment and have a fresh breath of air away from my computer from time to time.
With my personal experience, this is where ColdFusion on Wheels has entered and really brought the fun back into ColdFusion development.
One thing that Wheels has done for me is use CFCs to organize my code and make database queries easier. But at the same time, I don't feel like I'm wasting too much time worrying about the design of my objects. It all just flows and works organically, and it all works that way simply by following conventions that we've laid out for you. I will forever be amazed at what David Heinemeier Hansson has accomplished by implementing the concepts of Ruby on Rails and what these concepts accomplish for me in my life as a CFML developer through my use of ColdFusion on Wheels.
If you at all have felt CFML lose its magic in a way that Marc Funaro described so well, give Wheels a try. The more you uncover about our framework, the more it just makes sense. Our framework considers what ColdFusion as a platform does well and sticks with that. ColdFusion returns recordsets lightning-fast, so Wheels's findAll() methods return recordsets instead of CF's notoriously slow objects. (It also uses objects to represent data when that makes sense.) Wheels also helps you easily understand where your URLs point to in your code with its controller conventions. And hell, I'll even offer up the fact that Wheels's default URL behavior doesn't even give regard to the underlying platform. Having URLs that end with .cfm, .aspx, .jsp, etc. do nothing to contribute to the overall user experience anyway.
These sentiments bring me a lot of hope for Wheels's role in the CFML community. We're pushing forward and helping you develop beautiful code using the best platform for developing web applications, period.
replace your wheels folder from the one in the download, and
outside the wheels folder, ensure you've got a file at events/onabort.cfm and create it if needed.
rename any instances of findLast() to findLastOne() (this has been changed due to Lucee 5.3 having a new inbuilt function called findLast() which clashes with the wheels internals)
We are excited to announce the availability of ColdFusion on Wheels 0.9.1. I personally can tell you that the core team and community have really outdone themselves with this release. It is a giant step toward an impending release candidate.
Here is a brief listing of what Wheels developers gain from this release:
Ability to set global defaults for most functions' optional arguments
Upgrade-friendly configuration settings
Support for using multiple data sources (set on a per-model basis)
Ability to group view helpers by controller
Support for sending multi-part emails (HTML and plain text in same email)
New PluginManager plugin that helps you find and install plugins
Improved Railo support
Lots of bug fixes and other minor improvements
Review the Upgrading to Wheels 0.9.1 chapter to see what you would need to change in your application when upgrading.
Because of the big changes to the way that configurations are done, we figured this would be a good time to finish the chapter on Configuration and Defaults.
More reference chapters and documentation on the functions in the Wheels API are in the works, so stay tuned.
If you're attending cf.Objective() 2011, you'll have a couple opportunities to learn more about ColdFusion on Wheels. You'll also have access to a couple prominent members of the Wheels community at the conference, so be sure to say hi!
Speaker: Chris Peters
If you're new to the ColdFusion on Wheels framework and want to give it a try, then this presentation is for you.
This session will cover an overview of the conventions that the framework assumes and live coding demos of the built-in ORM, controller, and view layers. Learn how features like validation, callbacks, nested properties, filters, verification, and partials help you start coding now and clean up and refactor as you go.
Speaker: Mike Henke
You’ll spend the two days working through a single concept by creating a simple blog system and learning the basics of ColdFusion On Wheels including:
What: "Intro to Wheels Object Relational Mapping (ORM)", with Mike Henke
WHEN: Thurs. Jan 21, 6:00pm US ET (UTC/GMT-5)
MEETING URL: http://experts.acrobat.com/cfmeetup/
DURATION: Approx. 1 hour Meeting will be recorded. URL will be posted after meeting at http://recordings.coldfusionmeetup.com
ABOUT THIS SESSION:
Our 6pm (US ET) talk on Thursday Jan 21 will be "Intro into Wheels Object Relational Mapping (ORM)", with Mike Henke. (For an introduction to CFWheels, see the recording of the talk earlier this month by Chris Peters. More at http://www.meetup.com/coldfusionmeetup/calendar/12231118/.)
TOPIC DESCRIPTION: (provided by the speaker)
An overview of Object Relational Mapping (ORM) and how is it used in Wheels. Learn how ORM simplifies your database interaction code. Mapping objects in your application to records in your database tables is a key concept in Wheels. We will take a look at exactly how this mapping is performed.
This app has now been added to the list of Server-Side integration examples on the htmx website.
htmx at it's core is html over the wire. Instead of returning JSON from backend APIs and consuming them with Javascript to build page interactivity, htmx takes a different approach. It expects actual html snippets to be returned that are swapped into the DOM. How it does it, is by extending html with a handful of additional attributes, that probably should have been there in the first place, which enable any HTML element to issue an AJAX call to the backend, specify what triggers the call, and specify how the returned HTML should be added to the DOM.
We'll be doing more with HTMX in the future so it's great to get CFWheels on the radars of the htmx project.
Per whipped up a quick chapter on Sending Files with Wheels's sendFile() function.
You may feel that sending non-HTML files to the browser is a trivial task, but this functionality makes securing those files dead simple.
Thanks, Per!
callStackGet() gets invoked 2364 times in this example, but appeared performant, only causing 10ms execution time. getFunctionCalledName() is called the same number of times, but has a total execution time of 2242ms(!). We had our potential culprit. Either way, it was looking like the combination of calling the stack and trying to find the calling function name which was causing so much pain. I suspect it's to do with how Java deals with this: I think it might be calling a full stack trace and writing it to disk on each call - at least that was the hint from FusionReactor's thread profiler (I'm sure those who have a better understanding of Java's underlying functions will chip in).
After some deliberation, we decided to revert this behaviour in CFWheels 2.1 back to how it used to work in 1.x, as the vast majority weren't using it, but were being affected by it. We'd seen no plugins in the wild which used this behaviour either, which was largely undocumented.
Obviously thanks to FusionReactor for helping us out - hopefully this gives some insight into just one of the ways FusionReactor can be used. Maybe one day I'll understand Java stack traces - maybe.
