Hi MikeS,
Thanks for taking the time to document the process you followed, much
appreciated.
I have been quite keen on wrapping but there has been plenty of evidence of
people migrating side by side that I need to seriously consider.
Regards,
Michael
P.S. Thanks for the Ceiling Cat blessing - but you have unsettled my faith in
the Flying Spaghetti Monster ;)
On 10/12/2010, at 2:44 AM, Mike Seth wrote:
> On 12/02/2010 08:56 AM, Michael McHugh 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() ;)
> Hi,
>
> Sorry for the late reply. Indeed, I have faced this task in the past.
> Migrating PHP4 applications to Agavi is, well, an interesting task. In my
> case, as refactoring proceeded incrementally, a business necessity arose to
> add new features and bug fixes to the new codebase that's been refactored.
> So, refactoring and development of the new codebase were done simultaneously.
>
> Briefly, what I did is this:
>
> The old application (the "source") was put under version control. I prefer
> git because of its cheap branching, rebasing and other nice features.
> A new blank application (the "destination") was created. A point of note: the
> default setting of strict validation was removed from it temporarily, as it
> made refactoring very inconvenient.
> The database configuration was prepared in the destination application to
> match that of the development and production environment of the source
> application.
> I've went clicking around the old application, collecting its URL structure.
> This URL structure was then recreated in the destination app's routing map,
> with approximated names for modules and actions that weren't created yet.
> This gave me a rough layout of the destination application. In fact, Agavi's
> routing was a key mechanism in the whole refactoring endeavour.
> I've converted the master templates, CSS layouts and other minimum outfit so
> that the destination app looks and behaves
> I've written a similar authentication system and configured logging for the
> destination application. I've configured session sharing and database so that
> whatever's initialized in the source app is also accessible in destination
> (in my case, I had to use the horrible PEAR DBDO/MDB2 as the source app used
> it for schema and relationship management)
> At this point the destination application resembled a refactored skeleton for
> the source one, but did not carry any actual business logic from the source
> application.
> I've ported a single often used feature (an Action in Agavi terms) into the
> destination application.
> Using webserver URL rewriting and virtual hosting magic, I've deployed the
> destination application along with the source one in production under the
> same URL hierarchy as the source application so that the new actions I
> implement overshadow the existing ones.
> One by one, I've moved features from source to destination, without the users
> being able to take note, and organizing the priorities in such a way that
> newly requested features always fall on the code that's already been ported.
> As features migrated, I physically removed the code from the source
> application.
> Eventually I've arrived to the point at which the destination application
> fully replicated the existing functionality (while having a much more
> consistent structure), so I could turn off the legacy codebase entirely. At
> this time, I was able to start shaving the architectural warts, features that
> weren't needed any more, writing validation and unit tests. All in all, I was
> able to incrementally move the application from chaos to Agavi right in front
> of people's eyes and no one noticed.
>
> Notice that the key difference in my approach was that I did not "wrap" the
> source application in the framework; rather I had the new application imitate
> the environment of the old one, and the two were connected through URL
> mappings, a shared database and a logon session (I'm sure there was more to
> it than just this I just dont quite remember the details). This proved to be
> a great decision as I didn't have to muck with the old code at all; and
> working on rather small units of code (usually a single Action at a time) I
> was able to iron out most of the moronic idioms from the code as I went.
>
> In any case, good luck and Ceiling Cat bless you!
>
>
>
>
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.agavi.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.agavi.org/mailman/listinfo/users
