oooops - non FB3 compliant example, as HTML, HEAD, and BODY are (we presume) handled by fbx_layouts - i better clarify before i get shot.
Still, the concept is valid: cfinclude template="dsp_StuffBeforeTable1.cfm" cfinclude template="dsp_Table1.cfm" cfinclude template="dsp_StuffBetweenTheTables.cfm" cfinclude template="dsp_Table2.cfm" cfinclude template="dsp_StuffAfterTable2.cfm" /t ----- Original Message ----- From: t <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 29, 2002 5:58 PM Subject: Re: Queries and display files > Tom, > > Remember that the browser doesn't care how many files originally contained the > html used to make up a logical page - ie you could include other dsp files which > contain the rest of the html used to draw your page: > > cfinclude template="dsp_HtmlHeadandBody.cfm" > cfinclude template="dsp_Table1.cfm" > cfinclude template="dsp_WhateverGoesBetweenTheTables.cfm" > cfinclude template="dsp_Table2.cfm" > cfinclude template="dsp_CloseBodyandHtml.cfm" > > That will work if you absolutely, positively don't want to cfinclude > dsp_Table1.cfm and dsp_Table2.cfm from within another file... the tradeoff is > that it will be much harder to change that logical page - you may have to edit > up to five files... > > /t > > > ----- Original Message ----- > From: Tom Schreck <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, March 29, 2002 5:39 PM > 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 ==^================================================================
