in reply to LAMP and hosting: Convenient Perl solution, similar to PHP setup?

You've pointed to the old "issue" of ... “which came first, the webapp or the page?”

One school of thought (and by the way, such schools-of-thought exist in both the PHP and the Perl camps) says that you should always let Apache do what Apache does... serve-up a page, given its name. During the course of “serving up the page,” Apache discovers that the page contains executable code that it should run. That's the page centered approach.

The other school of thought argues that this is much too limiting, citing obvious examples such as “RESTful-ness,” in which the URI is taken to be the identifier of a resource that is not necessarily equivalent to a file. A single program intercepts all calls to the entire site, or to an entire region of it, evaluates the URI as one of its inputs, and by some means generates the appropriate response.

I find myself agreeing with the second point-of-view.

Going back to your final question, it's not at all difficult to get a Perl webapp running under shared-hosting. Simply make sure that your host is running a fairly-current version of Perl. Choose a convenient web-application framework in Perl, and set it up as per its instructions ... which no doubt will include very-specific guidelines for a shared hosting environment. Anything from Catalyst to CGI::Application can be pressed into service, and that's just with Perl.

You will undoubtedly find yourself setting up a local-to-yourself directory for the installation of CPAN modules, and module-versions, that are necessarily different from whatever the shared-hosting company has installed. It's easy to do; I've written on this topic myself here.

And then, just relax and dive in. No matter what approach you finally choose, it's going to feel weird the first few times you try it. Nothing to do with you, or with your site, or with the tool, or with Perl or PHP, your shared-host, or the phase of the moon. (Well, maybe the phase of the moon...) Just expect it, and move on. That's why it's usually best to set up a replica environment on your local servers, or even your own box, so that you can bash your head against the wall in quiet and peace. As you figure things out, keep a diary and take very careful, detailed notes ... because you will forget what you did and how you did it.

P.S.   For all the sites that I maintain, the authoritative copy is located on one of my servers, which is configured (as seen by this-or-that site) exactly like the appropriate host. Updating the site consists of tagging the files in the version-control system (to remember exactly what was “released today”), then using rsync to send the files up to the host. Testing is done locally, thanks to the /etc/hosts file and a slightly-different domain name (“.moc”), and I know that when the files go up to the shared-hosting site they will perform exactly the same as they do here. Work out such a system for yourself, document it (even for yourself), create checklists and procedures, and stick to them.

Replies are listed 'Best First'.
Re^2: LAMP and hosting: Convenient Perl solution, similar to PHP setup?
by kyle (Abbot) on Mar 12, 2008 at 20:30 UTC

    re "keep a diary"

    I'd call that revision control. On the other hand, browsing around revision history and commit messages isn't nearly as easy as a file that you made specifically to record discoveries, even if it is likely far more detailed and accurate.

[reply]

      Project management systems can have “diary” capabilities, and if they exist they should be used. But a revision control system can only hold ... a revision. And by the time a “revision” has been created and checked-in... well, by then it's just too late. You “gone and done it.”

        The "diary" of revision control is the commit messages. Even crusty old RCS featured this. I agree that a tool dedicated to this kind of work is better than what you get from revision control. I say that not having used them, but I have no problem believing there could be a better diary than what you get free with your revision control.

        You “gone and done it.”

        Sort of. The beauty of revision control is that you can then go and undo it. I find it useful to commit early and often, at just about anything that's a logical unit of change. It's just as easy to back out ten revisions as it is to back out one.

[reply]
Re^2: LAMP and hosting: Convenient Perl solution, similar to PHP setup?
by Anonymous Monk on Mar 13, 2008 at 00:13 UTC
    ... Choose a convenient web-application framework in Perl, and set it up as per its instructions ... which no doubt will include very-specific guidelines for a shared hosting environment.

    So how would I run CGI::Application persistently in a shared hosting environment? I couldn't find any mention of "shared hosting" in its documentation.

[reply]

      I cautiously agree with the other Devotees that the information you are looking for is “out there,” even right-here on this site. (Some of it was written by yours-truly, for whatever better-or-worse that might mean.)

      I also submit that you're going to encounter that requirement no matter what language or tool you are using. PHP may (or may not) be “the devil you know,” but you're going to have to do a certain amount of dancing with whatever devil comes to the dance.

      To give you just a little bit more guidance as to where to look to find the missing-pieces, let me very briefly outline what some of the essential “missing pieces&rdquo will be (even if some of these are done for-you):

      • You're going to be setting up a directory containing executable Perl programs, and those programs are going to include a use lib directive pointing to a local-to-you Perl-modules directory.
      • You're going to use CPAN, when you're logged on to the shared host via ssh, to install those modules into that local place. Which means that you'll be doing some reading about how to do that with CPAN...
      • You're going to use mod_rewrite rules, declared specific to your own virtual-host(s), which will transform incoming URIs and/or redirect them to your chosen Perl script.
      • Since you are using a machine that you do not and cannot administer, you'll be making local changes and directing both Apache and Perl to refer to them with regard to your site.

      Remember, none of this is “new.” (New to you, granted, but not new.) Even though your first impulse might be to go run screaming for the hills, it's actually just “four questions and no answers, yet.”

      So, it's time to do some research. You're really going to need to surf-the-books for a day or two as the little lights come on. Keep a diary, in the form of a legal pad and a sharp number-two pencil. When you have a question or a “show stopper,” write it down and then let go of it so it doesn't “stop” you anymore. Gradually, and with increasing speed, the lights will come on and the question marks on your legal-pad will be overwritten with checkmarks.

      “Then, a mere padewan you no more shall be. A guru you will have become...”   ;-)

      You consult the shared hosting environments documentation
[reply]

In Section Seekers of Perl Wisdom