This was what we found works best... 1. Make custom tags (or CFC's is the way we are going) and do your "nasty" code as "Content Handlers". This is a series of projects in itself, we are going to dig in here real soon. We (my family) moved across town and we are still unpacking this week. We think about content handling as a two stage process... stage one ->capture content (may have multiple capture calls) ... stage two -> convert content for rendering.
NOTE: Number 1 above is just how we do it... and we are also looking to use flash (which you mentioned) as a stage two tool. 2. Yes, the layout is the right(er) place to do it. You should collect data for things like your menu as you go. (If you are using a content handler, tossing your data into your structure does not require nasty code.) When your are done generating your page content you use the stage two handlers... or put the page in your choosen layout file. (Skin) That is the skinny on how we did it. There is more work up front for the first project, but when you get your tools built... boy, how things fly! What a dream! We are as I said... about to begin our MX version... anyone who is interested can come along. (Display handlers for ... grids, requestor, input response, IE IHTML editor (SOEditor), Menu's, Sidebars... and they will also have settings and parameters to make them flexable components for the developer... web objects is the common term I believe.) John Farrar >>> [EMAIL PROTECTED] 06/04/02 11:31AM >>> 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 ==^================================================================
