RE: FuseQ and XFAs

[hal helms]

Title: Message

I would have liked an immediate execution, but in the same http request. Otherwise, we just have a cfmodule, unless I've missed something profound. I think of this as analagous to the transition from C to C++. You can use basic Fusebox until you're ready/need to do something else. And that may be never. Or it may be that you need it once in a blue moon.   I haven't had any problems with integrating AddToQ() with normal <cfinclude>s. I don't see it as a fundamental shift in FB at all -- it just adds some very nice functionality. But I'm sure many people will be perfectly happy using FB3 just as it is. And "as it is is" pretty danged cool, IMHO. -----Original Message----- From: Lee Borkman [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 2:17 AM To: [EMAIL PROTECTED] Subject: Re: FuseQ and XFAs Thanks Hal,   Yeah, I'm sure looking forward to reading that book.  Both books.   As for FuseQ, yeah, I'm finding it very interesting, although I'm afraid that the available articles only scratch the surface.  For the rest, I'm just trying to intuit the uses of the various FuseQ functions by reading the code.  John has been very helpful too, when I have mailed him off-list.   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?  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?   As Patrick has noted, he has been using his own <CF_Call> tag to make recursive calls as simple as possible for some time now, although that still leaves the calls in their own seperate variable-space, and still entails the execution overhead of any recursive call.  I think.  Is that right, McE?  Patrick might well argue that the calls having their own variable-space is an excellent thing, and indeed that is often a good idea, a little more short-term hassle traded for a good deal of longer-term predictability.  I am sure that there must be ways to reduce the overhead of recursive calls.   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).  While that may please many web-development gureaux, I doubt that it will make novice coders feel more comfortable ;-)   Thanks again, matey, I can't wait to see the FuseQ error-handling examples.  My little brain can't yet imagine how that is going to work...   LeeBB ----- Original Message ----- From: hal helms   Lee, we have the ability to do what you want by calling the FB recursively (you can even call it recursively using multiple fuses in the FuseQ). That's covered in one of the chapters in John and my book and I'm sure Nat and Jeff cover it in their book.   John and I went over this very process of immediately executing an added fuseaction to the queue, but since the PRESENT fuseaction would have to be terminated, the code you show couldn't work (without a recursive call to the FB).   I've found that using FuseQ is extremely helpful in implementing Model-View-Controller architecture as well as abstracting common functionality to a parent. For example, if I have this circuit structure:   Employee    SalariedEmployee    HourlyEmployee    ContractEmployee   and if I then want to create a new employee (either salaried, hourly, or contract), I probably have some similar things I do for each of them. Rather than having duplicate code in each of the three employee types, I can abstract this to the Employee circuit and then use this code:   <cfcase value="new">    <cfset SuperQ() />    <cfinclude template="act_DoThis" /> </cfcase>   If I need the SuperQ to execute immediately, I can do this:   <cfcase value="new">    <cfset SuperQ() />    <cfset AddToQ( 'SalariedEmployee.doNew' )> </cfcase>   I don't know about the "atomic" argument, either, but the other stuff in FuseQ is sure nice. -----Original Message----- From: Lee Borkman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 9:15 AM To: [EMAIL PROTECTED] Subject: Re: FuseQ and XFAs It sure looks like it to me, JohnF.  You build up requests by throwing entire fully-qualified fuseactions onto the Queue (FIFO).  Each fuseaction gets executed in its turn, and as far as I can see, each fuseaction's internal workings (eg XFAs) are its own business. What I'm trying to get my head around is how to make use of the way the fuseactions are queued to be executed further on down the processing track.  That means you can't really mix up "immediate" code with FuseQ calls.  That's a little weird to me right now, because I have always mixed conditional code, etc directly into my fuseactions.  For example, this wouldn't work the way you might hope: <cfset addToQ(person.validate)> <cfif isValid>   <cfset addToQ(person.insert)> </cfif> I'm also grappling with the concept of "making fuseactions more atomic".  Is that a good thing to do?  Do I really want to create fuseactions in order to package up a single fuse worth of code? Obviously I'm looking forward to seeing some more examples.  I know Q was quite a hit up in the Arctic. See ya, LeeBB ----- Original Message ----- From: John Farrar   Does fuseQ still use XFAs? Thanks, John ==^================================================================ This email was sent to: archive@jab.org 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 ==^================================================================