>> Due to the size of the project and the lack of tools at the time, Fusebox >> wasn't attractive. So we basically rolled our own application environment.
this also sounds like us. 18 months ago, there was bugger all about frameworks. A start was made with Spike's Batfink a bit less than 12 months ago but in the end it's a "benorama" type MVC/MVP hybrid that suits the existing client/server (procedural) programmers to learn/migrate to. ...oh well, it works for us.. biggest regret (and too late to change): not further implementing xml as the transport medium between service and view layers and back again for complex data (we're only doing this in selected places instead of using multiple structs, arrays and descrete values). my 2c barry.b > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Roland Collins > Sent: Wednesday, 15 June 2005 2:04 PM > To: [email protected] > Subject: RE: [CFCDev] MVC and GetPageContext.Forward() > > > >Definitely agree with that. Why go to the trouble of dealing with all > >this stuff manually when you can pick a framework and get a > great head > >start? > >-- > >Sean A Corfield -- http://corfield.org/ > > In our case, this application is now 5 years old, and has a ton of > functionality. It is truly an enterprise application in terms of its > intended purpose and the size of its codebase. Due to the size of the > project and the lack of tools at the time, Fusebox wasn't > attractive. So we > basically rolled our own application environment. When it > was written, CFCs > didn't exist, so we developed a large library of cfmodules. > > The major reason we haven't migrated is one of practicality. > Our current > architecture works, scales well, is easily extendable and > customizable, and > is very easy to manage. It took us a half year just to migrate the > cfmodules to CFCs, and that was just using the CFCs as > function libraries. > Now that that's done, we're working on utilizing more OO code > where it makes > sense. But overall, rewriting the application to use a > framework at this > point for us just doesn't make sense. We've got a mature, > stable, very > well-received application, so there's no real reason for us to move. > There's no reason to migrate something that works perfectly > just for the > sake of being on a framework. > > That said, if I were starting a new application today, yes, I > would almost > certainly use a framework, but it would not be Mach-II - I'm > much more of a > fan of Model Glue at this point :) > > Cheers, > Roland > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [email protected] with the words 'unsubscribe cfcdev' as > the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
