>My impression is that John would have implemented an "immediate execution" solution except that it seems to be impossible or >near-impossible given the current limitations of cfscript. Is that correct, John?
I just felt that the amount of effort expended would only end up with the same thing as CFMODULE, and I was waiting for some more concrete examples of when it just HAD to get done. (So please suggest some) We've been finding that the need for CFMODULE turns out to be so rare that the costs involved with it are easy to pay. (Esp with MVC) > >Is there actually some particular benefit that comes from the deferred execution, or is deferred execution merely an unwanted by->product that pops up when solving the basic requirement, ie executing multiple fuseactions within the current variable space, and >without the other overhead that would result from a recursive call? but it's not really deferred, -- well it is, but you're in essence deferring it for just a few <cfset>s . That's why the idea of the "public" fuseaction, the one that starts it in a given request, being a "seeder" fuseaction has some benefit >Probably my biggest concern about FuseQ is that it could radically shift the common practice in Fusebox away from CFINCLUDE >towards AddToQ(), given that the two methods don't mix (not at a low level anyway). well one's AddToQ()'s would be put at the front or the end of a given fuseaction (it matters not). It jsut totally depends on how you want to handle things and *Where* what's being FuseQ'ed is located. If it's in the same directory then I see no need to use FuseQ in that instance. ==^================================================================ 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 ==^================================================================
