Tom, there are no rules that define what you can use in the fbx_layout to control which layout file is presented. i've used switches on fusebox.fuseaction, on fusebox.circuit, on attributes.fuseaction, cfif statements on the language variable (multi language site), and any combination of the above. i know it seems a little awkward at first, but after a few days, you begin to see the advantage of doing it this way.
2 day, 2 weeks, 2 months, 2 years down the line, you need to change something in the display, and you KNOW exactly which file you need to open to make it. fbx_layout besides, you can do a lot of cool things with those switches and cfif statements very ecomomically with just a few blocks of code. lots of leverage there when you figure out how to use it. nando Tom Schreck wrote: > 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 ==^================================================================
