Just another thought on content generation and menus. Normally I have a just a two level menu architecture, and this works great by relating fuseactions to menu options. Then the FB3 variables are available to tell you which 'level' you are in (IsHomeCircuit etc), which is the 'parent' menu option (TargetCircuit), and which is the current menu option (Fuesaction)
I just have a structure which describes the menu hierarchies, and provides an optional different menu option from the fuseaction. Bit more complicated if your menu uses images (why do that?), but not too difficult Cheers doug wrote: > What will my boss think when I start using the term "nasty code" <Off > topic > grinning> > > > ----- Original Message ----- > From: "John Farrar" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 04, 2002 11:07 AM > Subject: RE: content generation > > > 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 ==^================================================================
