Viewing by month: September 2005

Sep 29 2005

MG 1.0: Event Forwarding != Event Announcement

I had a feeling this feature may cause a bit of confusion, and I got my first comment on it last night.

While there *is* a method on the Core.Event object called Forward() that lets you pass the name of an to forward the event request to, this is *not* the equivalent of announcing a new event in Mach-II.

Where Model-Glue lies "between" Mach-II and Fusebox is that it implements II (like M2), but because of the <result> mechanism, it has a mapable route through an event request (like FB).

What the Forward() method literally does is immediately abandon any further processing of your event, place the data bus into session, perform a CFLocation to the specified event, picking the data bus back up instead of building a new one from url/form.

In other words, it's not something you'd want to use often! Where it's effective is a place that I and some others continually ran into a wall - special cases when we had something like a form in a "pod" in a "sidebar" on every page on a site, and needed to dynamically take the user back to the page they came from after submission. There just wasn't a way to cleanly do it with the <result> mechanism.

3 comments - Posted by Joe Rinehart at 6:45 AM - Categories: Model-Glue

Sep 28 2005

Model-Glue 1.0.01: GetSingleton() lives!

I mis-built the 1.0.01 to ignore the GetSingleton() method on the framework level. My apologize to the inconvenienced, you should now be up and running.

2 comments - Posted by Joe Rinehart at 11:12 PM - Categories: Model-Glue

Sep 28 2005

Model-Glue 1.0: Available for Download

Sometime this AM the current version number at www.model-glue.com began showing 1.0.00.

Yep, it's available. Should be pretty stable, as a number of people have been using much of the new code under the "bleeding edge release" for a while now. I'm not 100% sure of stability of Linux and OS X case-sensitivity issues (I lack a testing platform at the moment, feel free to donate a Mac to me).

Release notes for 1.0:

New Features:

Redirects: Framework can statefully redirect via the REDIRECT and APPEND attributes on the tag

Event Forwarding: A controller can forward the event to a new event handler, utilizing the same state preservation as redirects

Event Beans: Automagically populate CFC instances with methods named like setNNN()

Asynchronous Events: Framework can asynchonously fire a (CFMX7 Enterprise only, requires Sean Corfield's Concurrency library)

Queries in ConfigBeans: A query is now a valid type in a config bean, thanks to Jared Rypka-Hauer

Configurable Statebuilder: For SES and other purposes, you can replace the CFC used to build the viewstate, declaring your own in the block.

Added DTD (in /ModelGlue): Thanks, Jared, Sean, and others! Updated Code: Framework (ModelGlue.cfc) no longer configures itself: see XMLModelGlueLoader.cfc

Many of the config settings in ModelGlue.xml are no longer necessary unless the defaults need to be overridden. See: App Template's ModelGlue.xml and Metadata.Config

Misc. bug fixes and tweaks

Thanks to (in no particular order):

Doug Hughes, Scott Stroz, Sean Corfield, Jared Rypka-Hauer, Dave Carabetta, Raymond Camden, everyone on the Model-Glue listserv

13 comments - Posted by Joe Rinehart at 11:05 AM - Categories: ColdFusion MX | Model-Glue

Sep 28 2005

"Merrimack" (7.0.1) is available!

Get it while it's hot, get it while it's buttered. Download available at Macromedia's site. It's also interesting to note that the U.S.S. Merrimack was a scuttled United States frigate that the Confederacy rebuilt into an iron-clad, leading to a pretty interesting stalemate that could be seen as one of the first events in modern mechanized, armored warfare.

Download: http://www.macromedia.com/support/coldfusion/downloads_updates.html#mx7

0 comments - Posted by Joe Rinehart at 6:38 AM - Categories: ColdFusion MX | Model-Glue

Sep 27 2005

Business cases for Framework developers

A quick list of five reasons I'd hire a candidate with framework experience over one without. This isn't to say I'd avoid candidates without framework experience - if I could find someone with really good anti-framework reasoning, they'd probably be displaying most of these five!

Leading up to the Fusebox and Frameworks conference later this week, there's been discussion over whether or not "frameworks" are a good thing.

In accordance with my last post, I'm going to run the following statement before I keep writing:

<!--- define "framework" for the scope of this post --->
<cfset var framework = "Fusebox,Mach-II,Model-Glue" />

There's a set of business reasons as to why I'd hire a candidate with framework experience, and a desire to do more framework-based development, over a ColdFusion developer who purposely avoids using frameworks.

1. Common vocabulary

Before anything else, I know that a framework-based developer is going to "speak the same language," to some extent. Much like design patterns, that vocabulary of frameworks give developers common ways to simply convey complex concepts.

2. Safe cross-cutting implementation

Inside of the "big three" CF frameworks, I can rest assured that a developer can add cross-cutting concerns (examples: security, logging, behavioral changes) while performing minimal (or no) changes to existing code. This is an obvious benefit in terms of risk.

3. Community involvement

Unfortunately, I think there's a large population of what I call "ostrich" developers. These are developers who learned to write a basic CRUD application, gained self-confidence, then lost all interest in seeing how anyone else does anything, sticking their heads square in the sand.

My experience has been that someone with an active interest in frameworks is likely to be more interested in finding different or better ways to do things than their current skill set allows. Please not that this is statement is recognition of correlation, not causality. I didn't say that being a framework-based developer causes people to find better ways of doing things.

4. Portability

Working in the CF frameworks, people are going to encounter many of the same concepts that apply to other framework-based development environments (ASP.NET, Cairngorm, Rails, Struts, etc.). Therefore, it's probably going to cost me less money if I need them to work on a non-CF project.

5. Enforcement of better design

Using frameworks *forces* developers to think about how to do something. The rules of a framework exist for a reason - while some people may feel they're restrictive, it's usually because they haven't hit a point where the rules have come back to play in their favor.

9 comments - Posted by Joe Rinehart at 8:34 AM - Categories: ColdFusion MX | Model-Glue

Sep 27 2005

The framework argument is silly.

There's a strange discussion taking place across a few ColdFusion blogs over whether or not frameworks are a "good" thing. While my opinion is probably pretty obvious, I've avoided getting involved because I think the argument itself is an exercise in the absurd.

It's impossible to make an argument as to whether or not frameworks are appropriate for the same reason that two frameworks, chosen at random, can't be compared: oftentimes, it'd be an apples to oranges comparison. To blindly make an argument that frameworks are or are not appropriate is to ignore the fact that different frameworks exist for different purposes.

For example, while Fusebox, MG, and M2 are all presentation-layer frameworks, performing the "last-mile" connection of business model to HTML presentation, there's no way you could compare any of them to Tartan or ColdSpring because they serve very different and sometimes complimentary purposes.

Everyone should be willing and mature enough to recognize when usage of a framework is or is not appropriate, and make their choices of frameworks based on business needs, not personal preferences. Ironically, I'm a big advocate of Fusebox 4 within my own company, because we have a lot of CF5 folks who've never touched a CFC, and FB lets us play nicely together. However, if I needed to do an app as small as a simple one-page signup form for some event, I'd abandon the use of a framework altogether.

7 comments - Posted by Joe Rinehart at 8:00 AM - Categories: ColdFusion MX | Model-Glue

Sep 19 2005

Fee! Fie! Foe! Fum!

Sigh. For anyone who's ever done a large file download over BitTorrent.

"Fee! Fie! Foe! Fum!"
Joe Rinehart

Fee! Fie! Foe! Fum!
Will my Torrent ever be done.
Is it 'live, or or it dead?
My poor brain wants to go to bed.

3 comments - Posted by Joe Rinehart at 5:27 PM - Categories: Off Topic