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
