Thanks to everyone for their input so far.. SimonH, that is exactly the idea - be able to swap out parts as we go without having any (major) apparent differences for our end users (at least until it the migration has been completed, then I can go crazy and make the thing shine!)
The idea for us is to end up with a completely new code base that better fulfils our business and technological needs (there are also business risk and legal reasons, but hey - this is a tech talk list). The _current_ code performs its _current_ function without breaking, however there are just some things that can't be done without putting an inappropriate amount of effort into achieving the result - the technical debt is too high and the code smells are fetid - disparate date/time storage, no classes, no functions(!!) just include()'s, no db abstraction (not even PDO) - I have a 5 page document _outlining_ the smells. Oh yeah, the vendor only guarantees it to work on PHP 5.1. Sorry, starting to turn into a rant... JanS/SimonCPU, Historically we have bolted _new_ functionality onto the system with an alternate rewrite rule to Agavi, but enhancing or altering functionality is a different game. I would like to just write the thing from scratch, but we have over 70 clients (installations) that rely on our product so gradual upgrades would be much better that halting for 6 months and then migrating, educating and retraining all our clients. Regards, Michael On 06/12/2010, at 8:39 PM, Simon Holywell wrote: > This would make sense although if you are migrating the code to use > Agavi rather than just bolting Agavi onto the side of your application > for new code then I would have thought it better to route all traffic > into Agavi's routing first. If the route is not found in Agavi then > send it to the underlying legacy application. > > In that way you can quickly and easily swap out components by adding > their route to Agavi as you go. This would save you from having to > change URLs later or maintaining a big list of 301 redirects. > > 2010/12/5 Jan Schütze <[email protected]>: >> +1 >> >> I usually just create a specific set of routes, which go to the new >> agavi base (for instance ending with .html or a trailing slash /) and >> keep the legacy code intact. >> >> What you have to keep in mind, is that you might want to share the >> session. Be careful here and you will even have the ability to login >> into both at the same time! ;-). >> >> Regards, >> Jan >> >> On Sun, Dec 5, 2010 at 4:41 PM, Simon Cornelius P Umacob >> <[email protected]> wrote: >>> Hi! >>> >>> I tried migrating our old code base to Agavi too. What I did was I >>> created an alias to Agavi, so that only http://example.org/agavi would >>> use the new framework. I synced the templates so that the front-ends >>> on both frameworks were exactly the same from the user's point of >>> view. The storage backend (XML) and sessions (yepp, this is possible) >>> was unified too. >>> >>> I left much of the old code intact because I realized, "hey, why fix >>> something that isn't broken?" =) >>> >>> Regards, >>> >>> [ simon.cpu ] >>> >>> >>> On Thu, Dec 2, 2010 at 2:56 PM, Michael McHugh <[email protected]> >>> wrote: >>>> Hi Folks, >>>> >>>> Company I work for licenses the source code of a legacy system that has >>>> been drip feeding updates over the last few years and I have finally been >>>> given approval to migrate it to the Agavi framework (license allows us to >>>> change any code). >>>> >>>> I'm curious on any advice, tips, tricks or thoughts any others may have >>>> from experience doing a similar thing. A couple of my ideas on this are >>>> below.. >>>> >>>> 1/ The idea is to initially wrap the application in the framework and >>>> slowly refactor/extract parts of the original code into Agavi. I was >>>> thinking of using a default route that passed to a module/action pair of >>>> something like Legacy/Default that simply called the appropriate legacy >>>> script. >>>> >>>> 2/ Legacy code has significant use of globals and $_POST, $_GET, $_REQUEST >>>> and $_COOKIE variables...<shudders> so in factories.xml would need to set >>>> the 'unset_input' parameter to false on the AgaviWebRequest object. Until >>>> this was addressed anyway. >>>> >>>> And just to vent because I am the only coder on this project - this legacy >>>> beast uses include('someFunction.inc') as if it were equivalent to >>>> someFunction() ;) >>>> >>>> Regards, >>>> Michael (@AlchemyCS) >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.agavi.org/mailman/listinfo/users >>>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.agavi.org/mailman/listinfo/users >>> >> >> >> >> -- >> >> http://dracoblue.net >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.agavi.org/mailman/listinfo/users >> > > > > -- > Simon Holywell > simonholywell.com > > _______________________________________________ > users mailing list > [email protected] > http://lists.agavi.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
