I like to architect things so that each fuse isn't dependent on another.
However, there's always workarounds that fit within the specifications:
If one of the fuses would be nested inside of another, I'd CFSaveContent
the fuse at the application level (fbx_switch.cfm):
<cfsavecontent variable="fuseContent">
<cfinclude template="dsp_myFuse.cfm">
</cfsavecontent>
Then specify fuseContent in the input area in the fusedocs of
dsp_myOtherFuse.cfm
---
Billy Cravens
-----Original Message-----
From: Tom Schreck [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 29, 2002 10:39 AM
To: [EMAIL PROTECTED]
Subject: RE: Queries and display files
Thank you Billy. This helps out a lot.
I have a situation where I have the need to have 2 dsp_XXX pages show up
under the same <cfcase> in fbx_switch. If FB3 methodology prefers you
not <cfinclude> one of the files inside the other, then how do you
control where to place the 2 files? Each individual file is developed
as a standalone <table>, so how do I control the positioning?
Thanks - Tom
-----Original Message-----
From: Cravens, Billy [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 29, 2002 10:32 AM
To: [EMAIL PROTECTED]
Subject: RE: Queries and display files
The premise behind Fusebox is encapsulation and "black boxing". Each
fuse does its own thing, and doesn't need to know what other fuses do.
All it needs to know is what data to expect. The connections and
dependencies are handled by the application files (fbx_)
You're right - when moving fuses, you would need to have the correct
data moving along with it. This is why we use Fusedocs. When I move
dsp_searchResults, I know that I need a recordset named rsSearchResults.
Now, that recordset may come from my existing qry_getSearchResults. Or
I may move it to a new application, and provide it with a new file,
qry_newSearchResults, or a qry_ file that already exists in my new
application that returns the appropriate data. The beauty is that I
wire this up at the application level without having to modify
dsp_searchResults (as you would in your example)
This applies within circuits as well. Many times I use fuses in
multiple fuseactions that don't always use the same combination of files
(only the definition of the data is static)
If I will be using the original qry_ file, I only have to look at my
fbx_switch to determine dependencies. This way, I know that's the only
place I ever have to look. Otherwise, everytime you move fuses, you'll
always have to scan the fuses for <cfinclude> tags, rather than relying
on the consistent structure of fbx_switch and fusedocs (which are always
in the same place)
---
Billy Cravens
-----Original Message-----
From: Tom Schreck [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 29, 2002 8:49 AM
To: [EMAIL PROTECTED]
Subject: RE: Queries and display files
I have the queries located in their own file, I cfinclude/cfmodule them
into the page needing the recordset. Why should you cfinclude/cfmodule
a query inside the <cfcase> of the fbx_switch file versus
cfinclude/cfmodule the queries inside the dsp_XXX file itself. When you
want to re-use dsp_XXX somewhere else, you have to remember to also call
the appropriate queries. If, on the other hand, the queries are already
cfinclude/cfmodule inside the dsp_XXX file then you are good to go. So,
I'm wondering from a design perspective why I would separate the query
calls outside of the dsp file needing the recordset?
Thanks
Tom
-----Original Message-----
From: Nelson Winters [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 28, 2002 5:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Queries and display files
A couple other reasons are:
1. Separate queries into their own file in case a dba who doesn't know
CF
very well can access the queries without messing up anything else.
2. To provide modularity so that the same query can get used in multiple
fuseactions.
----- Original Message -----
From: "Douglas Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 28, 2002 5:08 PM
Subject: Re: Queries and display files
> One reason is so that the index file becomes more self-documenting.
You
> can see straight from the index file, the dependencies of any given
> fuseaction. If you modify a query fuse, you can do a quick scan of
the
> index file to see which pages/fuseactions it will affect, and you know
that
> you will need to test those fuseactions also.
>
> At 02:25 PM 3/28/02 -0600, you wrote:
> >I know true FB3 methodology calls for separating query fuses from
display
> >fuses, but does this not produce more work having to remember to
include
> >calls to queries 1,2, and 3 before calling display page X? What's
the
> >reason for not putting all necesarry query calls within the display
page
> >itself?
> >
> >Thanks
> >
> >Tom Schreck
> >[EMAIL PROTECTED]
> >817-252-4900
> >
> >I have not failed. I've found 10,000 ways that won't work.
> >
> >- Thomas Edison
> >
>
>
>
==^================================================================
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
==^================================================================
