CF.Objective

Mach-II Monday: Tears, and Sunshine

Well, I managed to pull it off... with a wee bit of help.

I have a working OO class for doing a2rss conversions (which isn't exactly right... it applies the supplied XSLT to the supplied XML doc and returns the resulting document) that I wrote last night. So since I have to start the handheld app for the client, I decided to run thru the Mach-II process using an HTML form to supply the URLs/paths.

First of all, setting up the app was a snap, thanks in large part to Trond's previously mentioned newbie doc and a few key points I'd missed in my reading. Setting up the first event, the form, and the view was easily done in Homesite+, and setting up the listener to connect with atomCFC's API was also very easy.

All-in-all, I found my first real venture into OO to be fantastically rewarding. Things went together better, stayed together better, and were more flexible than I've previously been able to accomplish. I think the assembly went faster and, frankly, now that I'm much more familiar with CFCs than I used to be, the whole process is pretty cool.

But, I found something about Mach-II that I really don't like. Anymore, it won't be an issue, but I think it's counter-intuitive, and since there's enough CFOO newbies, I'll mention it because I could NOT find the answer anywhere.

In the Mach-II.xml file is a common set of entries, and I emulated them to the letter:

< event="feedRSS" access="public">
< listener="feedListener" method="getRSS" resultkey="request.rssText">
< name="feed" contentkey="request.content">


That makes a great deal of sense to me, and fits with my overall impression of the framework. "Take resultKey from listener, supply it to request.content for transmission to the page. Great, a built-in transfer object... my presentation is automagenically abstracted from my logic. Hoorah!

Nope. Ain't so. And nobody, but nobody that I could find had explained where the resultKey went after it had been returned to the resultKey. I changed contentKey to the same as resultKey, and it quit erroring out, but I had absolutely no content.

Well, apparently, as Yoda explained it, the framework sets resultKey to the value returned by the listener. What contentKey actually does is aggregates content, for things like composite pages, so that you can compile several different contentKeys and output them in mainTemplate.cfm, for instance.

This, I think, makes no sense. I would prefer to see the view-page attribute named resultKey for aggregating results... and the contentKey attribute capable of retrieving a value from the event object. It's consistent, more aptly named, and separates view from logic to a greater degree.

That would give us something like this:

< event="feedRSS" access="public">
< listener="feedListener" method="getRSS" resultkey="rssText">
< name="feed" resultkey="content.part1" contentkey="rssText">


When it executes, the listener method returns the resuts of method, which gets inserted into event.{resultKey}. ViewHandler would then:
setContentKey("{contentKey}", event.getArg("{resultKey}"))

Once setContentKey executes, {contentKey} is available in the request scope, which acts as a conduit between the model and the interface. The specified view is implicitly either rendered to the screen or passed back to whichever module handles aggregating screens for podlike outputs based on the presence of a resultKey attribute in the view-page tag.

It just makes more sense to me, I guess...

But, it was explained to me that I could use the event-arg tag in the event-handler block to move the data from the resultKey into the event object:


< event="feedRSS" access="public">
< listener="feedListener" method="getRSS" resultkey="rssText">
< name="rssText" variable="request.rssText">
< name="feed">


Which, I assume, would mean either writing an event facade to give a view access to event data, or using event.getArg() calls to return data to the screen. I like my idea better, though.

I really DO like the idea of using the request scope as a conduit, and I really do like the Mach-II ideal for MVC and even-driven applications. The thing I don't like is the strange naming convention and lack of abstraction from listener response -> request scope -> view.

Anyway, I am now... (checking...) going on 7 hours late for my trip to the gymn, so I must leave. However, despite my travails, I DID get it to work (with a little help from my friends) and the end result can be viewed here. Let me know what you think!

Laterz,
J

posted by Jared @ 1:53 PM