Although it may not be tasteful to some, you could put some positioning
table code right in the fuseaction. This seems like a reasonable Fusebox
compromise to me.
<cfcase...>
<table><tr>
<td><cfinclude template="dsp_file1.cfm"></td>
<td><cfinclude template="dsp_file2.cfm"></td>
</table>
</cfcase>
At 10:39 AM 3/29/02 -0600, you wrote:
>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
==^================================================================
