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 ==^================================================================
