in reply to Best Practice for Replacing Globals

As a side note, unless you need to hardwire yourself to Apache, looking at porting to mod_perl seems like a more difficult path than porting your existing code to a modern framework like Mojolicious(Re^2: Best Practice for Replacing Globals) or Dancer.

  • Comment on Re: Best Practice for Replacing Globals

Replies are listed 'Best First'.
Re^2: Best Practice for Replacing Globals
by hippo (Archbishop) on Apr 20, 2023 at 08:31 UTC

    I have to say that this has not been my experience. It has proven quite easy in the past to migrate old, crusty CGI-based applications to mod_perl using ModPerl::Registry and especially so compared to having to re-engineer the entire codebase to work with a new framework.

    The various web frameworks are fine for green-field projects but impose a significant burden on the developer when migrating in an existing application like this.


    🦛

      "compared to having to re-engineer the entire codebase to work with a new framework."

      "The various web frameworks are fine for green-field projects but impose a significant burden on the developer when migrating in an existing application like this.

      In this use case, mojolicious has you covered, adding one hook allows the existing codebase to work as expected. I've used this in the past without issue.

      "I have to say that this has not been my experience."

      I've rewritten several legacy CGI::Application codebase with Mojolicious/(or Mojolicious::Lite), the learning curve wasn't steep, I ended up with something faster, fewer lines of code and less cludgy than before. Of course YMMY

      Update: Also, for the uninitiated, mod_perl binds you to using Apache.

        adding one hook allows the existing codebase to work as expected. I've used this in the past without issue.

        Thanks for the link - that's very interesting. I will give it a go in due course with the latest project and see how that pans out.


        🦛