On Wed, Apr 29, 2009 at 4:58 AM, Matt S Trout <span dir="ltr">&lt;<a href="mailto:dbix-class@trout.me.uk">dbix-class@trout.me.uk</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, Apr 27, 2009 at 01:54:12PM -0500, Michael Reddick wrote:<br>
</div><div><div></div><div class="h5">&gt; Does anyone have any advice for migrating a large mod_perl app that has no<br>
&gt; tests to catalyst?<br>
&gt;<br>
&gt; I already know of Catalyst::Controller::WrapCGI which seems to be a good<br>
&gt; start.<br>
<br>
</div></div>Assuming your app doesn&#39;t use apache specific stuff.<br>
<br>
What I tend to recommend in such cases is to start writing new functionality<br>
in Catalyst as FastCGI and just map chunks of the URI space across to the<br>
new stuff. When you need to significantly alter the old code, port it first.<br>
<br>
Eventually you&#39;ll just have a Catalyst+FastCGI codebase, and you&#39;ll have had<br>
working code at every stage.<br>
<font color="#888888"><br>
</font></blockquote><div><br>I&#39;ve done similar things, and my new method is to have a two tiered application where my Cat app sits in front of legacy, and on unhandled URLs throws a 404.  The front-end proxy (Varnish, in my case) then restarts the request against the next backend, which is the mod_perl system.<br>
<br>Then, when I put in new features in Catalyst if the URL is changed I can simply put in a permanent redirect and everything just works.<br><br>This is roughly a new technique, and lacking some fine tuning points, but so far I&#39;m very happy with it.  I wrote up a posting about my implementation (which has some other nits): <a href="http://our.coldhardcode.com/jshirley/2009/04/varnish-and-movabletype-for-co.html">http://our.coldhardcode.com/jshirley/2009/04/varnish-and-movabletype-for-co.html</a><br>
<br>-J<br></div></div>