For me, while B is unacceptable, A is impossible. I can't afford to go through hundreds of old websites making minor tweaks unless I can persuade clients to pay for it. Of course, clients (at least my clients) don't want to pay to upgrade to a new version of a framework - only to add new functionality to the site. Usually clients will only pay enough every 3-5 years to justify making substantial changes to their site (as opposed to just making a requested tweak or adding a requested feature) so the sites languish and every few years they get a rebuild.
It is one of the most fundamental problems in software engineering, and while you can mitigate by capturing declarative requirements so you can just regenerate sites without effort on newer languages/frameworks (that is one of my design goals for my generator - sufficiently generic templates and metadata that I could automate the regeneration on any programming language or version without site specific effort), but firstly this is hard to do and secondly, as your metadata grammar evolves, you find you've not removed the problem but just lessened it a little. If I add a new code feature, I don't have to re-code, but if I add a new grammatical feature to my metadata I need to add information to that extra field (or whatever) to be able to regenerate. Best Wishes, Peter On 12/15/06 5:10 AM, "Barry Beattie" <[EMAIL PROTECTED]> wrote: > Denny: please forgive me for butting in here but you've articulated > the kind of angst we've been going thru with a greenfield project/new > start for us. > > it's not just reactor, but other frameworks (model-glue, fusebox, > etc), taglibs, el al. > > I've worked with both bringing the apps along with new versions or > letting them sit (and be maintained) in the old version. there's pros > and cons for both. > > but I can't help be inspired by Alaire/MACR/Adobe working hard to > ensure CF4.5 code will (99%) run on a CF7 box. heck, it's not the > grief ASP classic -> ASP.NET went thru. > >> Pretty much random philosophical blather- carry on. > > perhaps not. How about a quick Vox Poll - both with Reactor and > frameworks generally? > > (A): "Bring along the crappiest oldest website at the same time as the > newest shiniest one == as soon as we step up a version (locally, of > course- ;) we start seeing failures, fix those, continue on. > > - or - > > (B): "leave the old stuff in the dust, hoping never to have to go back > to it again, or if so, we can turn back the clock in our heads, so we > code in the same time as the code was written" > > I'd vote "A" but geeze it's sometimes a lot of work... > > anyone else with their choice? > > thanx > barry.b > > > > > On 12/15/06, Denny Valliant <[EMAIL PROTECTED]> wrote: >> Shared hosting is the only place where I'd opt for NOT using a mapping. >> It would be almost criminal to use 'em there. For MG, Reactor, CS, etc.. >> >> Other than that tho: >> >> Personally, I feel it's as bad to have 11 projects using different versions >> of the same framework as having 11 separate frameworks. Not bad, >> actually, but still, sorta counter the idea of FW, right? >> >> Better to just pin a version, and stick to it everywhere, or not, I guess. >> >> One man doesn't have a problem remembering what's available for >> what project, anyways. Just ddepends on how you work, and keep >> organized, etc. >> >> If we were coding right, we'd have unit tests and concurrent running >> tests etc., etc., which would make it pretty moot no matter what >> you're doing. Man, if I had eight arms, maybe. Or many years... >> >> Yeah, that's what I'd opt for. Bring along the crappiest oldest website >> at the same time as the newest shiniest one == as soon as we step >> up a version (locally, of course- ;) we start seeing failures, fix those, >> continue on. >> >> Or else we don't: we leave the old stuff in the dust, hoping never to >> have to go back to it again, or if so, we can turn back the clock in >> our heads, so we code in the same time as the code was written, >> not making dumb mistakes like using a feature that hasn't been >> invented/implemented yet. >> >> There's no right answer here, if you ask me; much like everything >> else. FWIW, I, personally, being the sole man on many projects, >> LOVE having reactor in one place for all of them. It was a PITA >> to do it any other way, even with SVN:externals. But I highly >> recommend the use of svn:externals for those cases where you >> do have to maintain separate copies of, say, Reactor for CF. >> >> Like my site on a shared host. >> >> Mostly this sentiment comes from the sheer joy I just bestowed >> upon myself by moving everything to mappings. It relates more >> to my "models" now being able to talk, vs. framework locations, >> so really- do what you have to do to get the job done there- but >> WOW, mappings are good for your "model". Er, are good for >> *my* model. my Newer models. *cough* yeah. Sorry for getting >> carried away here folks! =] >> >> Pretty much random philosophical blather- carry on. >> >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> -- -- >> Reactor for ColdFusion Mailing List >> [email protected] >> Archives at: >> http://www.mail-archive.com/reactor%40doughughes.net/ >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> -- -- > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
