O CGI como padrão, foi uma idéia legal, o que, há 15, 20 anos?
Na prática, comparado com o que temos disponível hoje, CGI é uma
desgraça e as gambiarras criadas pra "melhorar" a performance, vulgo
mod_perl, por exemplo, tornam a vida um inferno todo dia.
Não me venham com esse papo de "não compensa". O que não compensa é
ter que fazer na mão em cada CGI o que o Catalyst me entrega pronto.
Por exemplo, eu morro um pouco toda vez que eu tenho que escrever algo como:
my %actions = (
foo => \&action_foo,
bar => \&action_bar,
);
my $action = sanitize( CGI::param('action') );
$actions{ $action }->( { map { $_ => sanitize( CGI::param( $_ ) ) }
CGI::param } );
...
ou pior
if ( $action eq 'foo' ) {
action_foo();
}
elsif ...
...
Se sua aplicação é nova, faça um favor a si mesmo, use Catalyst.
Se sua aplicação é um micróbio ou prova de conceito, use Mojo::Lite.
Agora me convença que vc não cai em nenhum dos dois cenários acima,
excluindo código legado.
[]'s
2011/10/20 Eden Cardim <edencar...@gmail.com>:
>>>>>> "Nilson" == Nilson Santos Figueiredo <aci...@gmail.com> writes:
>
> Nilson> É mais simples porque você simplesmente pega o script CGI e
> Nilson> envia por FTP e pronto, tudo está rodando. Todos nós
> Nilson> sabemos das desvantagens, mas não tem como negar que é muito
> Nilson> mais simples.
>
> E o qual o problema de fazer isso com Plack, por exemplo?
>
> --
> Eden Cardim
> Software Engineer
> http://bit.ly/edencardim
> http://twitter.com/#!/edenc
> +55 73 9986-3963
> =begin disclaimer
> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
