On 12/30/06, Dave Merrill <[EMAIL PROTECTED]> wrote: I think of the controller as the orchestrator, the one who examines the > context, calls the models needed to get any data required, then passes > that to > the view for rendering. He's the traffic cop, kinda.
Precisely. That's a much better way of saying what I was trying to say. I have a strong preference that CFC methods be passed the info they need as > arguments, rather than fishing it out of "the air" themselves. That makes > it > very clear what inputs they expect, and makes them testable, becuase you > can > easily feed each little piece disembodied test data outside the normal > complexity of the real app. Agreed wholeheartedly. That is precisely the reason I've been having the argument with myself that I've been having. For that to happen, you need some kind of app structure that gathers the > incoming data (typically including form and url scopes, maybe others), and > calls the requested method of the requested CFC. It can be very simple, or > something more full-featured. This is the part that I've been struggling with, but I *think* that it's becoming much clearer to me after reading the replies to this thread. Which is a plus, because sometimes you (read: I) sit and stare at the screen or books for hours studying something and it just becomes a confusing mess after awhile, given the variety of opinions on the topic-at-present. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create robust enterprise, web RIAs. Upgrade & integrate Adobe Coldfusion MX7 with Flex 2 http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:265407 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
