Re: FuseQ and XFAs

Lee Borkman Sat, 18 May 2002 00:03:01 -0700

Title: Message

Now you guys are both saying that and it's beginning to confuse me - cfmodule calls are within the same HTTP request, or am I losing the plot? Same request, different variable space.

And what I mean about mixing cfincludes with addtoQ() is that you can't do this (well, you can but it doesn't do what you might hope):

... and this one is certainly no good:

</cfif>

Neither of these works, because the execution of the queued fuseactions is deferred.

Anyway, I'm just being a good open-minded sceptic. Is there some functionality that I get from FuseQ that I could not duplicate using cfmodule, albeit with a little more fiddling around? (That's not meant to be a provocation, just a question.)

Thanks again,

LeeBB

----- Original Message -----

From: hal helms

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]]

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
==^================================================================

==^================================================================
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
==^================================================================

Re: FuseQ and XFAs

Reply via email to