I've been doing this identical thing since around the days of fb2, skinnable sites or no. Even wrote up a little custom tag that appends to a variable, rather than writes to one (very handy for for when you have multiple, sequential dsp_ fuses that all need to write JS (or whatever) to the page. I do the same thing for style, the BODY onload handler, page title, and various other site-specific things (like menubars, sidebars, whatever). Even for non-skinned sites, it is immensely helpful in generating pages that have all the parts in the right locations (SCRIPT and STYLE in the HEAD and such).
However, that's not the problem I'm having. With JS, for example, your dsp_ fuses write it directly, and it can then be output to the page. With the menu, it's a two step process: 1) generate the menu content structure from the db (very nasty code). 2) turn that into HTML, JS, whatever (maybe flash at some point) for display. Step two happens in my skin-specific templates, as you would expect, because one has a vertical menu layout, another has a horizontal, another has a non-dynamic version, etc.. However, step one has to happen before that, and it's not skin specific at all. In fact, it's not even circuit specific, it's consistent across every page in the entire application. The question I have is regarding placement of the content generation code, completely ignoring layout. The code basically does this: run a bunch of queries (mostly cached), and generate a big nasty struct of arrays of structs referenced by 'request.menus'. Then in the skin code, it traverses that struct and outputs menus into a variable as it sees fit, and then later puts that into the page where it belongs. As I see it, there are two potential places for the generation code to go: fbx_Settings.cfm or fbx_Layouts.cfm. Both have their pros and cons, which I briefly addressed on my first post. I'm currently leaning towards fbx_Layouts.cfm, but I'm curious as to what the 'right' solution is. cheers, barneyb -----Original Message----- From: John Farrar [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 5:33 AM To: [EMAIL PROTECTED] Subject: Re: content generation Hey, I have used this technology for several customers. If you are a former fusebox 2 programmer this will make sense... we did it in fusebox 2 and use it in fusebox 3 also. Rembemer "bodycontent"... we would drop it in a variable with a custom tag. Now we use "layout". That is a "CONTENT BLOCK". In our web page we have several content blocks. - Header - Sidebar - Menu - Body (layout) - Footer - DevNotes If you are not using savecontent in CF5 let me know. ... We take the content and toss it into a variable and direct it at the layout collection. Another thing we do is to use style sheets. This allows the content to be updated in colors, fonts, etc. on the fly and user by user. You can also swap which layout you are using on the fly user by user. You see it does not matter what user you is using your site. They will have the same building blocks. Some will have Sidebars, some will not. When you toss the content into a "CONTENT BLOCK" you achieve the ability to move the pieces of your site around without the need to recode your core application. WOW!!! Modular content, sounds like a good idea! If you need more information let me know. John Farrar >>> [EMAIL PROTECTED] 06/03/02 07:30PM >>> I'm currently putting the finishing touches on an app that will be 'skinnable'. Skinnable includes not just colors and such a la WinAMP, but also layout (vert/horz menubar, left/right 'extras' pane, etc.). I generate my menu content into a nasty collection of structs and arrays. The content doesn't depend on the page being viewed, but it is generated from a database. In each skin's files, the structs/arrays are distilled into actual HTML and JS for display. I'm running into a quandry as to where to put that code. My initial placement was in fbx_Settings.cfm. However, the menu content obviously has nothing at all to do with the application's execution, so it doesn't really belong in fbx_Settings.cfm. A friend and I were discussing it, and he suggested fbx_Layouts.cfm as the proper location. My feelings are that fbx_Layouts.cfm should be executed only after all the content is generated, and only presentation remains, but I'm lacking conviction. Really, it belongs in the same place as the app's fuses, executed during the content generation phase (after fbx_Settings and before fbx_Layouts), but there isn't any such place other than including it above the CFSWITCH in fbx_switch.cfm. I'm putting it in fbx_Layouts.cfm; is there a better solution? cheers, barneyb --- Barney Boisvert [EMAIL PROTECTED] 360-671-8708 (work) 503-267-2200 (cell) http://www.piersystem.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002 ==^================================================================ 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 ==^================================================================
