Lee asked a question about the immediacy of the FuseQ calls. They're not
immediate, the methods are designed to manipulate the FuseQ which you should
think of as "what will happen as the current fuseaction is complete?" If you
need soemthing immediately executed that is a CFMODULE type of thing to do.
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.
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.
Now, if someone can tell me if CFMX allows CFMODULE requests to be made via
CFSCRIPT then I have a solution; otehrwise we will have to wait until
Macromedia decides to make CFSCRIPT implemented fully. It's truly a language
limitation at this point.
Back to Lee's question: If you have to mix up immediate code with FuseQ
then you do want to use CFMODULE. However in working with FuseQ over the
past 4+ months I've found that most of my "immediate" needs were addressable
in anotehr way altogether. For example, I will often use the initial
fuseaction (ie, the one you might see in the URL) to act like a "seed"
fueaction which just populates the FuseQ and then gets out of the way, and
then FuseQ will take care of the rest. This covers a large portion of the
"immediate handling" problem space. Also, if the fuses are all in the same
physical directory, you really don't even need FuseQ for that fuseaction:
<cfcase value="myFA">
<cfinclude template="dspDoThis.cfm">
<cfinclude template="dspDoThat.cfm">
</cfcase>
is just as easy as
<cfcase value="myFA">
<cfinclude template="dspDoThis.cfm">
<cfinclude AddToQ( 'mycircuit.DoThat' )>
</cfcase>
in fact, I'd say the first one in the prefered method. The real power of
FuseQ becomes apparent when accessing code in multiple circuits.
Lee also asked about atomicity (is that a word?). FuseQ doesn't promote
more atomic Fuseactions just for atomicity's sake. What is does say is that
the smaller a given fuseaction is the more likely it can be used again in
conjunction with other fuseactions in new and different ways and for other
purposes.
so:
<cfcase value="DoHouseholdChores">
<cfinclude template="actWashTheCar.cfm">
<cfinclude template="actCleanTheLoo.cfm">
<cfinclude template="actPruneTheGarden.cfm">
<cfinclude template="actMakePopcorn.cfm">
</cfcase>
is much less pliable you might think. All of those fuses are implicitly
requires in the same directory or a work around must be found to handle
them. They are related to each other only insofar as being commonly called
by the DoHouseholdChores fuseaction, but otherwise they may independently be
part of other things like "relaxOutside" or "WatchAMovie" or
"WhatToDoAfterAKegParty" and those are not much related to DoHouseholdChores
so then check this out:
<cfcase value="DoHouseholdChores">
<cfset AddToQ ( 'cars.WashCar' )>
<cfset AddToQ ( 'housecleaning.CleanLoo' )>
<cfset AddToQ ( 'garden.Prune' )>
<cfset AddToQ ( 'movies.MakePopcorn' )>
</cfcase>
now it's possible for these fuses to be other circuits doing other work, yet
still have *the same code* available for the Do HouseholdChores fuseaction.
It will entirely depend on your application's need
----- Original Message -----
From: "Lee Borkman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 17, 2002 9:15 AM
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: [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
==^================================================================
