> > user_people = home/admin/people > admin_people = home/admin/people > > ...there will only be a single reverse lookup for home/admin/people - which > resolves to the first definition, in this case - user_people.
what your describing is the "multi-aliased" circuit concept that I'd introduced last spring, but it was dropped in FB3 for simplicity's sake. It also makes some sense that if you have two different names for a circuit then you likely are dealing with two kinds of objects. (Not that FB is object-based but there's a lot to be said for considering circuits as philosophical objects) > problem for me when using fusebox.thisCircuit - it will always resolves to > user_people regardless of which circuit I'm browsing from. Luckily, I can > just use fusebox.circuit, but it's a little misleading . Not sure whether > this is desired functionality or not. the API variable #fusebox.circuit# is the actual circuit garnered from the Attributes.Fuseaction fully qualified fuseaction. As long as it exists, that is. When that circuit does exist it will be the same value as the API variable #fusebox.targetcircuit# -- the "where is my target switch statement?" question. the API varialbe #fusebox.thiscircuit# refers to which circuit the core file is operating in *at that instant*; it changes as the Russian Doll is unwrapped reading fbx_Settings files from Top to Bottom. It changes when the fbx_Switch is reached. And then it changes as the Russian Doll is re-wrapped from Bottom to Top. Here, I'm using "top" to mean "home circuit" and "bottom" to mean "target circuit" > > Most people might not have multiple circuits pointing to the same directory, > but in my case, I do this so I can create multiple contexts for which > various users see the circuit. I use this in conjunction with a permissions > system; maybe I should JUST use the permissions system to dictate the > context? so you're tying the content to the display *and* the permissions/security? whew! be careful, that can be so dangerous, esp 6 months from now when you've forgotten what you've done. Trying adopting a more MVC-type design pattern and the need for multi-aliased circuits will likely drop away. You'll have more code you can re-use later on, and the overall construction of your current app will be simpler. ==^================================================================ 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 ==^================================================================
