Hi, Thanks for this. I really appreciate it. Essentially we have two choices - implement the mother of all fusebox index.cfm files for all our sites, or modify the core fusebox files to get to files not in the path below what you call root.
Problem is, both of those are workarounds right now, and not the most elegant solution. But I do appreciate the effort you have gone to to share this with us. What seems to becoming clear here is that I am not the only one experiencing this "problem". Wouldn't it be nice if we could do this (assuming you need to reuse "content" in both apps, below): Somewhere/how then, if the fbx core files would pick up that "components" is not in the directory path. Perhaps we could mark it, like I have done, with a leading ! (which means get the real path from a potential "fbx_mappings" file, or even get it from the CF administrator mappings - but let this choice be the user's and don't break anything). Fbx_Cicuits file for www.SiteOne.com: fusebox.Circuits.root="root"; fusebox.Circuits.omforetaget="root/siteOne"; fusebox.Circuits.sjalspa="root/siteOne"; fusebox.Circuits.openspace="root/siteOne"; fusebox.Circuits.creativeintelligence="root/siteOne"; fusebox.Circuits.konsultering="root/siteOne"; fusebox.Circuits.referenser="root/siteOne"; fusebox.Circuits.admin="root/siteOne/admin"; fusebox.Circuits.users="root/siteOne/admin/users"; fusebox.Circuits.content="root/!components/content"; <--- reused fusebox.Circuits.anna="root/siteOne/admin/users"; Fbx_Cicuits file for www.SiteTwo.com: fusebox.Circuits.root='root'; fusebox.Circuits.main='root/siteTwo'; fusebox.Circuits.about='root/siteTwo/about'; fusebox.Circuits.inspiration='root/siteTwo/inspiration'; fusebox.Circuits.graphics='root/siteTwo/graphics'; fusebox.Circuits.illustration='root/siteTwo/illustration'; fusebox.Circuits.multimedia='root/siteTwo/multimedia'; fusebox.Circuits.contact='root/siteTwo/contact'; fusebox.Circuits.content='root/!components/content'; <!--- reused fusebox.Circuits.clients='root/siteTwo/clients'; Thanks again. Steven > -----Original Message----- > From: Nando [mailto:[EMAIL PROTECTED]] > Sent: 20 May 2002 12:03 AM > To: [EMAIL PROTECTED] > Subject: RE: Code reuse / drag-and-drop > > > Steve, > > If you are running all these apps on the same server, you can > easily do > what you are after by setting up a "multi-application > application" like > i have done. your root fbx_circuit.cfm would have some > conditional code > in it as below: > > <cfif server_name IS "www.siteOne.com"> > <cfscript> > fusebox.Circuits.root="root"; > fusebox.Circuits.omforetaget="root/siteOne"; > fusebox.Circuits.sjalspa="root/siteOne"; > fusebox.Circuits.openspace="root/siteOne"; > fusebox.Circuits.creativeintelligence="root/siteOne"; > fusebox.Circuits.konsultering="root/siteOne"; > fusebox.Circuits.referenser="root/siteOne"; > fusebox.Circuits.admin="root/siteOne/admin"; > fusebox.Circuits.users="root/siteOne/admin/users"; > fusebox.Circuits.content="root/siteOne/admin/content"; > fusebox.Circuits.anna="root/siteOne/admin/users"; > </cfscript> > <cfelseif server_name IS "www.siteTwo.net"> > <cfscript> > fusebox.Circuits.root='root'; fusebox.Circuits.main='root/siteTwo'; > fusebox.Circuits.about='root/siteTwo/about'; > fusebox.Circuits.inspiration='root/siteTwo/inspiration'; > fusebox.Circuits.graphics='root/siteTwo/graphics'; > fusebox.Circuits.illustration='root/siteTwo/illustration'; > fusebox.Circuits.multimedia='root/siteTwo/multimedia'; > fusebox.Circuits.contact='root/siteTwo/contact'; > fusebox.Circuits.clients='root/siteTwo/clients'; > </cfscript> > <cfelseif server_name IS "www.siteThree.com"> > <cfscript> > fusebox.Circuits.root='root'; fusebox.Circuits.main='root/siteThree'; > </cfscript> > </cfif> > > Your root fbx_settings.cfm would need the same conditionals, just > setting a default attributes.fuseaction for each site. > > In the above example, although i have not done so, you could make any > directories you choose to be common to any of the > applications. If you > wanted to change layouts, you could put the same conditional > code in the > relevant fbx_layouts.cfm and you have it. if you need to > change DSN's or > other global settings for the app, ditto. > > If that's what you need and want to do, you can do it without any > problem from the fusebox angle. I just don't know if i would want to > have all my apps entanged in this way. i have a very diverse set that > i've worked on. ;-) Good Luck. > > n. > > Steven Ringo wrote: > > Hi, > > > > Nando, thanks for your lengthy reply. > > > > The difference, is that we *do* have lots of "parts" of > applications > > that need to be reused. And they are reused in there > entirety, with > > no changes to the core code. The layout does change, but that is > > inherited from the core layout of the application I am working on. > > The database DSN also changes, as each app uses one their own > > database, but again this is inherited from the main. > > > > Just as examples of some of the applications we re-use: > > - Forums > > - Security and user management > > - Content editing > > - File uploading > > Etc. > > > > I see your point - in many cases I have done this too - dragged and > > dropped 90% of an application and changed what I needed to > change to > > suit. An yes, I do have some copying to do, (e.g. the > database). But > > the principle revolves around proper source management > really: Lets > > take content editing, for example. This is more than just a custom > > tag. And this is designed so it never changes from app to > app. If it > > does change, I typically want to enhance the functionality, and let > > the enhancement roll out to all the apps using it. I would much > > rather change it in one place, than change it once, and then have > > distribute to "n" places. In some cases "n" can be 10 or more. > > > > Think about this too - if you can reuse 90% of your app and have to > > manually change the last 10%, surely you should (I know this is > > difficult) "remove" the core 90% and encapsulate that on > its own, and > > keep the remaining 10% somewhere else. In an ideal world, > of proper > > code-reuse, we *should* be able to do this. > > > > Up to now FB has been a way to code my code in a pseudo-OO fashion. > > With CFMX, some of problems with FB are solved, as I can > encapsulate > > the functionality into a CFC - (wow)! But the fact remains, > > Macromedia have realised that the same code is going to be > reused and > > have allowed for the use of a CFC repository. I really think FB > > should allow ofr the same. Of course CFCs allow for > inheritance and > > extensions too, but that's another story... Sigh :-) > > > > Thanks again > > > > Steve. > > > > > -----Original Message----- > > > From: Nando [mailto:[EMAIL PROTECTED]] > > > Sent: 19 May 2002 09:44 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: Code reuse / drag-and-drop > > > > > > > > > Steven, > > > > > > Theoretically, i could agree that you may have a point here about > > > precisely "drag and drop" anything anywhere being > > > "problematic". But my > > > hit on this is that in the world of web applications, you > hardly ever > > > need to do the exact same thing in 2 applications. The only > > > thing that > > > has practically remained consistant across all my > > > applications has been > > > my login circuit for the admin section. And that i just copy > > > and paste > > > into place. > > > > > > Once an application is developed for a particular client, in > > > many cases > > > that code is going to reside on a web server somewhere, > so it often > > > makes more sense to keep all the files for a particular > application > > > together in one directory tree. the component model might be > > > useful on a > > > large company intranet for instance, where all the files > resided on a > > > single server. But to me, to split them up all over the > place would > > > create a maintainance headache. > > > > > > So practically speaking, what i wind up doing, and most > > > people on this > > > list might agree, is not exactly drag and drop, but more > like drag, > > > drop, and tinker a bit. This is how i would say most of > us reuse code > > > with fusebox. and without the fusebox architecture, that > becomes much > > > more complex. With the fusebox architecture, you know exactly > > > where to > > > tinker and what to do. > > > > > > So i wind up creating a lot of new functionality / > appearance out of > > > code i've already written very efficiently. And > practically, in the > > > world of web applications where you are usually creating > > > relatively many > > > more applications than you would using a more traditional > computer > > > language like C++, and very custom applications at that, this > > > system of > > > drag drop and tinker seems to work out rather well. The > > > modularity and > > > structure of fusebox allows you to change exactly what > you need to > > > change, know exactly where it is, and leave the rest as is. > > > > > > My hit on it. > > > > > > Nando > > > > > > > > > > > > ==^================================================================ 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 ==^================================================================
