Oh, true enough, Tim. Trust you to pick me up when I am getting sloppy ;-) I guess it all depends on the granularity of the context-sensitivity, etc. Is there one set of nav for each circuit, or is it different for each fuseaction? As always, we are blessed with many ways to approach this.
The technique you mention is excellent, and offers very fine granularity, as you say. The layout template expects an array of navigation data (text and corresponding fuseactions), which can be set at the circuit level and extended/amended at the fuseaction level. The layout template decides what it wants to do with the nav data, ie it decides how to present the navigation. A perfect example of separating content from presentation. In Tira's case, the nav data is coming from a database, and we don't know if there are issues of context-sensitivity. If the nav bar needs to go and query a database and then present the data, then I would still be very tempted to create a dedicated fuseaction. I think I'd need to have some more detailed info to really figure that one out. As for <cfmodule> calls per se, I don't worry at all about the overhead, at least not at first. If I think the "nicest" way is to use <cfmodule>, then that's what I'll do. Following testing, if the performance of the cfmodule call is causing any problems, then I can replace the <cfmodule> with something else. If there is no need to scrounge a couple of milliseconds, then I'm happy. See ya round, LeeBB ----- Original Message ----- From: Timothy Heald <[EMAIL PROTECTED]> > Re: dynamic nav barLee, > I would disagree. I still use what you guys taught me earlier. I > generate an array of a structure, with keys like url and imageName or > linkText. Then loop over that to create a navigation area. With the added > overhead of CFMODULE, vs. the speed with which CF handles arrays and > structures I cannot see why you would want to make recursive calls like > that. > > The added benefit here is that it is very easy to have this generate > different menus down to the fuseaction level. If you are setting up a > fuseaction for it, you are probably only going to be able to do it easily > down to the circuit. Unless you are going to create a nav fuseaction for > each content/display fuseaction you have in that circuit, and then you are > doubling the number of cases you have and such. > > I think this way has the most flexibility so far. > > Tim > -----Original Message----- > From: BORKMAN Lee [mailto:[EMAIL PROTECTED]] > > Hi Tira, > > I would create a separate "navbar" fuseaction (possibly in its own > circuit). The "navbar" fuseaction would query the database and display a > menu based on that data. > > Then, in the site's main layout, I would use <cfmodule> to invoke the > navbar. > > If you want the navbar to be context-sensitive, then you'll probably want > to pass in an additional attribute in your cfmodule call, possibly > context="fusebox.targetcircuit" or similar. > > As ever, with these recursive <cfmodule> calls, watch out for infinite > loops in your layouts. > > Hopw that helps, > LeeBB > -----Original Message----- > From: Tira Cole [mailto:[EMAIL PROTECTED]] > > sorry.... populated from a database > > > -----Original Message----- > From: Drew Harris [mailto:[EMAIL PROTECTED]] > > What do you mean dynamic? > Based on security permissions or what? > -Drew Harris > > On 6/17/02 7:14 PM, "Tira Cole" <[EMAIL PROTECTED]> wrote: > > > Could anyone offer any suggestions on incorporating a dynamic > navigation bar into a fusebox site? I am very new to fusebox so any > suggestions, tips etc will be most appreciated. > > Thanks in advance > > Tira > > > > > IMPORTANT NOTICE: > > This e-mail and any attachment to it is intended only to be read or used > by the named addressee. It is confidential and may contain legally > privileged information. No confidentiality or privilege is waived or lost by > any mistaken transmission to you. If you receive this e-mail in error, > please immediately delete it from your system and notify the sender. You > must not disclose, copy or use any part of this e-mail if you are not the > intended recipient. The RTA is not responsible for any unauthorised > alterations to this e-mail or attachment to it. > > > ==^================================================================ 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 ==^================================================================
