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 Steven Ringo wrote: > Hi all, > > Thanks for the responses to the thread "FuseQ and sharing fuses among > apps". > > I would like to re-look at this topic, but without specifics. > > My aim is to find the best way to drag-and-drop fuseactions so that they > can be used in multiple applications. Especially if they are retained > in a repository designed specifically for reuse. > > Let me take a step out of the box, and attempt to describe the "problem" > mentioned in that thread, without referring to mappings, fuses and > so-on. > > Either I have missed the boat somewhere and do not understand how > accomplish a specific task using fusebox, or indeed Fusebox (and other > variations thereof) cannot address my "problem". > > - A definition: "Application". Application is a set of fuses and > fuseactions that reside in a specific directory tree on one's webserver. > The application is accessed through an index.cfm file in the root > directory of that application. Code in the deeper directories is > accessed through defining the appropriate paths in the fbx_cicuits.cfm, > and then calling the FuseAction appropriately to "get there". > > - The "professors" of fusebox keep emphasizing code reuse, and > "drag-and-drop" reuse. I agree that FB does this very well, but it does > seem to rely on directory locations on the disk, in that all fuses and > fuseactions must reside in the same directory, or deeper, than the point > at which index.cfm for a specific application is called. Can someone > confirm that this is indeed correct - I have not been able to show > otherwise. > > Reusing code in FB3: If I wish to "drag and drop" an entire fuseaction, > that belongs in a completely *different* application (in a different > directory, or even hard drive for that matter), then how do I do that? > Or stated differently, I want a common REPOSITORY for a whole lot of > fuseactions that can easily be dragged and dropped into my applications. > > Possible Answer 1: > Physically COPY all the files from the one application to the other and > update circuits files and XFA's appropriately. > Problem: What happens when I modify the code in the drag-and-drop fuse? > Must I make updates to all the instances where I have > dragged-and-dropped this code? If so, this is not only > counterproductive, but can lead to synchronization problems. > > Possible Answer 2: > Use CFMODULE, and use this to call the other application's fuseaction. > That works, partially, but I cannot share variable scopes between the > two applications - a drawback in that I would like to keep certain > settings, layout, Data source names etc. This is apparently where FuseQ > comes in, leaving many calls to CFMODULE behind, and overcoming some of > the drawbacks that CFMODULE presents, like variable scope sharing. > > I am hoping that fuseboxers better understand my problem, if indeed I > have a problem... > > My proposed solution? > > Keep using the fbx_cicuits.cfm file for "application" mappings - as you > need to be able to tell the application what FuseAction is "mapped" to > what directory of fuses. > > Also, to use some sort of other mapping system that does not restrict > you the deeper levels of the directory tree in which the application is > placed. Rather to let you reuse fuseactions that are located anywhere > on the webserver. > > Examining the upcoming CFMX - it does this like so, for CFCs (ColdFusion > Components) - it lets me describe where my CFC is, and it does not have > to be located near my application. It can be in a CFC repository if I > want. This is done through calling the CFC as so : > > <cfinvoke component="appResources.components.tellTime > "method="getLocalTime"> > > In this example appResources can be located in the root of where your > application is being called, or in another arbitrary directory. In the > latter case, you then have to map appResources in the CF administrator > to tell CF where it is on the disk. > > So this could be e:\wwwroot\appResources\components\tellTime > Or if you setup a CF mapping can be > d:\mycomponents\appResources\components\tellTime > > Can fusebox do the same thing with regard to physical code location? I > don't think so. > > Looking at other programming environments: > > C++, Delphi etc. allow you to define reused classes etc. through > defining library locations. I can use these in more than one > application from anywhere on the disk. I never have to recopy the code > for a class in order to reuse it. > > Fusebox currently does not allow anything like this. My suggestion is > to be to extend FB (and hopefully FuseQ) to do this, i.e. by letting you > your define circuits in a similar fashion as what CFMX does with CFCs. > > In conclusion: Unless I am mistaken, this is a major failing of > Fusebox: Code cannot be reused among applications, without physically > copying the code, keeping it the same directory tree or making messy > workarounds. > > I look forward to debate around this. > > Thanks all. > > Steven > > > ==^================================================================ 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 ==^================================================================
