|
Re: CGI Replacement Recommendations?
by tilly (Archbishop) on Feb 08, 2011 at 20:56 UTC
|
The standard these days seems to be Catalyst. But http://www.mojolicious.org/ looks very promising.
If you want to keep writing scripts very similar to the ones you were writing, you might also want to learn PHP. But that is not a very good language. | [reply] |
|
|
| [reply] |
|
|
Success and quality are only tangentially corrected. See Worse is Better for a classic essay on this theme.
As I've commented many times, PHP is good for beginning programmers. It is easy to get simple things done. It is cheap to find hosting. It is easy to get started. So people do. They build useful stuff. People build on it. The language is successful.
But the language itself is bad. It is very large, and disorganized. There are a ton of security holes in PHP. Even more in the popular applications. I've long commented that Larry Wall is better at hacking communities than languages. But for all the faults that Perl has - and it has quite a few in my opinion - PHP makes Perl look well designed.
All of that notwithstanding, PHP is a very popular language. It is easy to find work in it. Much of said work is solving the same problems (albeit more efficiently) that were being solved by Perl CGI programs 15 years ago. So someone who is used to the Perl CGI space may well find PHP to be a good fit in terms of problems. I was giving it an honest recommend as a job option for the original questioner. I was just being clear that it isn't a language for language snobs.
| [reply] |
|
|
| [reply] |
|
|
Re: CGI Replacement Recommendations?
by chromatic (Archbishop) on Feb 08, 2011 at 21:50 UTC
|
What kinds of tasks do you need to use? If you give us more information on what you're doing, we can recommend more specific information.
Catalyst is a good choice for writing web applications in Perl -- no one should look at you askance for doing so. It has a learning curve, but it's powerful and flexible and can handle complex applications.
CGI is an execution model, though. It's a standard for how a web server can launch and interact with a program to generate an HTTP response.
| [reply] |
|
|
Catalyst is a *great* choice for writing web apps in Perl. It performs quite poorly under CGI though - compiling all of that module code for each request is a killer. It really needs to run under mod_perl or FastCGI.
| [reply] |
|
|
| [reply] |
Re: CGI Replacement Recommendations?
by graff (Chancellor) on Feb 09, 2011 at 05:57 UTC
|
You should take a look at CGI::Application. Starting from a "pure CGI" background, I found it to be very easy to learn, and very appealing in terms of how I can structure my applications.
A really nice feature is the native support for your choice of template systems. (I happened to pick Template::Toolkit, which is quite powerful but well documented and easy to manage, but you have others to choose from.)
Another nice feature is that it's really easy to add new operations (as new pages) in your app, with minimal muss or fuss. Overall, you end up having to write a lot less code than you would with pure CGI, and it tends to be better organized and more coherent.
UPDATE: Having seen the reply below from Your Mother, I'm going to start looking into the recommendations there myself. (But I'll remain open to the possibility that for some developers, CGI::Application is "far enough" along the path that it will suffice for a certain range of web applications.) | [reply] |
|
|
I think this is the best answer so far (++). It leads to the question ... is "CGI the protocol" clunky? OR is "CGI the implentation" (fork/exec) clunky? Or is "CGI the CPAN module" clunky?
The protocol is fine.
The implementation *may* be clunky for certain classes of web applications but in your average environment (decent sized machine with reasonable user base), the fork/exec model is really not as bad as everyone thinks. 50K - 100K hits per day is not going to stress a decent setup.
As for the CPAN module. I always consider CGI to suffer from multiple personalities. The one personality is a top-notch CGI (the protocol) parameter parsing beast that should not be dismissed. The other personality is a mediocre templating system that should be avoided like the plague (IMHO). The great thing Lincoln did was create the module in such a way that using CGI for it's parameter handling features alone is possible and you're not really incurring any penalties by ignoring the HTML generation/template features.
So yes, CGI::Application combined with a decent templating system is the next logical step from a pure CGI approach.
| [reply] |
Re: CGI Replacement Recommendations?
by Sherm (Sexton) on Feb 09, 2011 at 01:38 UTC
|
The major problem with CGI is that it launches your script for every request. For large frameworks such as Catalyst, which can use dozens of modules, the startup time can be huge, making CGI impractical.
Popular replacements for CGI are mod_perl, which embeds libperl as an Apache module, and FastCGI, which runs your script as a separate long-lived process. Although they interact with the server in very different ways, they both accomplish one key goal - they avoid the heavy startup costs by compiling your code once, then executing it many times.
| [reply] |
Re: CGI Replacement Recommendations?
by luis.roca (Deacon) on Feb 09, 2011 at 15:29 UTC
|
Slightly building off the OP's question:
Are technologies like Mojolicous, Catalyst or Perl Dancer a replacement
or enhancement for CGI? This is the thing (admittedly one of many) I get
confused about.
I downloaded and installed Mojolicious last night. I've read through the
site and joined the mailing list a few weeks back. As far as I can tell
it 'supports' CGI, mod_perl, and FastCGI.
So does this mean that the OP would be able to happily take his CGI
scripts and have them run nicely under Mojolicious or will he have to
learn something new? Would someone like me who has fumbled around with
PHP for a few years need to go back and learn CGI first or could I just
get going with Mojolicious (or Dancer etc.)?
As much as I've searched there doesn't seem to be clear analysis of this.
"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote
| [reply] |
|
|
These three are "middleware" frameworks that can adapt CGI (or a stand-alone server, or mod_perl, or FCGI, etc.) to some internal, "unified" structure, more often based on a class hierarchy or a dispatch hierarchy than not. CGI "only" structures its path hierarchy using the file system, and launches a new process for every request, while other protocols have persistent processes between requests.
| [reply] |
Re: CGI Replacement Recommendations?
by Your Mother (Archbishop) on Feb 09, 2011 at 20:17 UTC
|
I want to follow up on what graff and derby said because this is absolutely right-
So yes, CGI::Application combined with a decent templating system is the next logical step from a pure CGI approach.
But it's why I recommend against doing it. It's the next step in the series but not the end, so I say. Unless you're doing it as a learning exercise, I'd skip right to Dancer, Mojolicious, or Catalyst.
I like Catalyst a lot but I'm pretty impressed by the steam Mojolicious has and the fact that it does websockets out of the box.
Plack is a really important development in modernizing the idea of CGI. Make sure to check out the links to it others posted. All of the well behaved frameworks have plack integration now so it won't influence your choice much, just the power and range of your code deployments.
| [reply] |
Re: CGI Replacement Recommendations?
by fenLisesi (Priest) on Feb 09, 2011 at 16:50 UTC
|
| [reply] |
|
|
"The links you will get with psgi plack, in particular plackperl and simon cozens, may help. "
As a side note I was a little disappointed to see Simon Cozens talking about Perl and web frameworks on a site built using Drupal *(At Least That's What Appears To Be The Case — hopefully I'm wrong). Especially since one of his projects, Maypole, lead to Catalyst and now Mojolicious. Maybe I'm reading too much into it.
Obviously he and everyone else are free to use whatever they feel works best for them. Like I said, just a little disappointed.
"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote
| [reply] |
|
|
At least his site renders readable :p
| [reply] |
|
|
Sorry to disappoint. :) It isn't meant to be a reflection on the quality of my code or anyone else's is. It's just that my days of hacking software for fun are more or less over, so I wanted to free myself from the pressure of running code that I maintained. Drupal seemed to be the best tool for the job. Likewise Memories is still a great site for photo hosting, but if Flickr is going to do the same job for me, then hey, I'll happily hand the work and responsibility to someone else. ;-) - S
| [reply] |
