FuseQ is a core file created by JohnQ and Hal Helms and is available from www.techspedition.com
It opens up some interesting avenues for MVC and error handling within Fusebox3 and is well worth checking out...it's not a competing methodology/framework, it merely builds on FB3, extending options open to the developer. John. > -----Original Message----- > From: Jeremy Ridout [mailto:[EMAIL PROTECTED]] > Sent: 18 May 2002 20:39 > To: '[EMAIL PROTECTED]' > Subject: RE: FuseQ and XFAs - huh??? > > > Help! Im lost. > > Can someone please explain what FuseQ is? I must've missed > something because I have no idea. > > Is it FB4 or an extension to FB3? Is it a competing > methodolgy/framework? > > Thanks, > Jeremy > > > -----Original Message----- > From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]] > Sent: Saturday, May 18, 2002 2:47 AM > To: [EMAIL PROTECTED] > Subject: Re: FuseQ and XFAs > > > > >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 message has been checked for all known viruses by UUNET > delivered > through the MessageLabs Virus Control Centre. For further > information visit http://www.uk.uu.net/products/security/virus/ > _____________________________________________________________________ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/ ==^================================================================ 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 ==^================================================================
