> John wrote: > > I spent a long time wrestling with the CFMODULE issue. > FuseQ eliminates a HUGE amount of the previous need for > CFMODULE just be virtue of the fact that "in this > fuseaction request" now no longer means "right away" > because FuseQ gives you an infinite number of fuseaction > possibilities within the same page request. So there will > only be a few times when you need something > right-now-no-matter-what. For that you need CFMODULE. CFModule allows just as much opportunity for "an infinite number of fuseaction possibilities within the same page request." I can't think of a reason why I would call a fuseaction and not want it to execute the moment I call it. Can you give me an example?
Actually, I'm a little concerned that this adding fuseactions to a queue concept could get unwieldy. With CFModule, one fuseaction call is nested in another. The fuseaction I originally called is always in control. It asks other fuseactions to do certain tasks, but then control returns back to the calling fuseaction. In your model, the starting fuseaction hands off control to the next fuseaction. Oh, dear, John, no, say it ain't so! Have you resurrected the GOTO statement? ;-) > After about a month of fiddling and constant prodding > by Mr. Helms on the CFMODULE question, it became clear > that the code I'd have to write to replace CFMODULE > would be just as long, or longer, to type in as the > corresponding CFMODULE request. Where were you and Mr. Helms when I shared my cf_call tag? <cfmodule template="#fusebox.rootPath##self#" fuseaction="foo.bar"> <cf_call fuseaction="foo.bar"> Patrick ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
call.cfm
Description: Binary data
