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
