As it currently stands, if you put direct calls to layout files in fbx_switch.cfm, you'll break Fusebox's inherent nested layout functionality, which expects layouts to be specified through fbx_layout.cfm.
When dealing with complex layout issues, it's helpful to remember the very powerful technique of using cfmodule to call a fuseaction. This is one way to create a layout with a variety of display components, arranged however you need them to be. - Jeff On Friday, March 29, 2002, at 12:37 PM, 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 ==^================================================================
