Re^2: Integrating codebases: namespace pollution, passing objects, and more

The codebase is huge -- 350+ modules, written in a mixture of procedural and OO styles, no separation of concerns (e.g. html and js mixed in with perl), no tests, etc. Rewriting it would be optimal but not practical for my current circumstances, which is why I would like to "sandbox" the old code somehow so I can use it without too much modification.

Comment on Re^2: Integrating codebases: namespace pollution, passing objects, and more

Replies are listed 'Best First'.
Re^3: Integrating codebases: namespace pollution, passing objects, and more by RonW (Parson) on Feb 28, 2017 at 01:02 UTC
One possible way to sandbox the CGI code is to run it in it's own process or thread. Depending on that code's behavior, you might not have to destroy the thread/process after each request. Another possibility is to let the webserver run it and have your Dancer app either send a redirect to the user's webbrowser, or send it's own HTTP request to the webserver. Obviously, if you go the redirect route, the CGI app wil have to be modified to include a redirect back to the Dancer app in it's response to the webbrowser's request.	[reply]
Re^3: Integrating codebases: namespace pollution, passing objects, and more by Anonymous Monk on Feb 27, 2017 at 18:58 UTC
So just sandbox a bunch of old crap and hope it holds up, again, for another 10 years ... good luck with that.	[reply]
Re^4: Integrating codebases: namespace pollution, passing objects, and more by Anonymous Monk on Feb 27, 2017 at 21:35 UTC
Thanks -- it's creating the sandbox to prevent namespace pollution, etc., that this question is about.	[reply]