I gather from this thread that the content would be displayed in a linear order. Meaning the first dsp_XXXX file is rendered and then the second dsp_XXXX file is rendered and so on. This assumes the output would be "stacked" on top of each other, the second dsp_XXXX layout starts right after where the layout for the first dsp_XXXX file stops. I have several situations where I need to place a <table>...</table> (the content from another dsp_XXXX file) in parallel order to its surroundings. Am I looking at this incorrectly, or am I making this too dificult?
I've played around with having a <cfswitch><cfcase> statements is in the fbx_layout file triggered on the fuseaction to know which layout file to pull. This allows me to truly have dsp_XXXX files separate from each other, but this does not seem to be a best practice. It uses the layout files as the glue to hold the different dsp_XXXX files together. Am I on the correct path here? If so, does it make sense to set the layout file inside the <cfswitch><cfcase> statements in fbx_Switch? I'm already using fbx_Switch to tell fusebox which fuses to pull, why not tell it which layout file to use as well. If none is specified, then use the default layout fuse. I appreciate everyone's help and suggestions. Thanks - Tom -----Original Message----- From: t [mailto:[EMAIL PROTECTED]] Sent: Friday, March 29, 2002 10:58 AM To: [EMAIL PROTECTED] 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 ==^================================================================
