[SP-pm] Validar session no Catalyst

[Nilson Santos Figueiredo Jr.]

2011/7/13 Eden Cardim <edencardim at gmail.com>:
> Na verdade, eu tenho trabalhado bem pouco com Catalyst e perl em geral
> ultimamente. Não sei se você viu na outra thread, eu sugeri o
> happstack. Ultimamente tenho experimentado muito mais com lisp,
> javascript e haskell, e sim, é difícil voltar pro Perl em alguns casos,
> mas a disponibilidade de componentes no Perl pelo cpan ainda é
> imbatível. Por sinal eu colaborei com o Matt Trout no design de dois
> frameworks alternativos, o Reaction, o Web::Simple e o HTML::Zoom (cujo
> design inicial foi meu), exatamente por não estar satisfeito com o combo
> Catalyst+DBIx::Class+TT. Voltei a usar num projeto aqui porque é mais
> fácil terceirizar, mas pessoalmente não estou mais usando porque não
> aguento algumas limitações que o catalyst tem. Inclusive, uma delas o
> André Walker tá resolvendo no gsoc.

Fiquei curioso: que vantagens você acredita que Javascript tem sobre
Perl, como linguagem? Não consigo pensar em nenhuma.
O HTML::Zoom é um conceito bem interessante. Comecei a dar umas
brincadas com ele uns 8 meses atrás... contudo, a sensação que tive é
que ele estava meio "incompleto" parecia mais "proof-of-concept" que
algo acabado. Mas o conceito é ótimo.

> Não acho, só acho que é um problema de documentação, não de
> implementação, e é um problemão, o pessoal do Catalyst/Moose/DBIx::Class
> não é muito bom de documentação.

Eu acho que não basta documentar. Por exemplo, é bem documentado que
quando se usa orientação a objeto, o objeto é passado como o primeiro
parâmetro e, normalmente, damos o nome de $self a essa variável. Todo
mundo sabe disso.
No entando, eu prefiro 42 milhões de vezes mais escrever:

  method foo ($arg) {
      $self->blablabla($arg)
  }

Do que:

  sub foo {
      my ($self, $arg) = @_;
      $self->blablabla($arg);
  }

Documentar não resolve esse problema. Documentar resolve o problema
somente de quem está aprendendo a usar aquela ferramenta, em outras
palavras, a documentação serve para listar as excentricidades de algo.
É tipo um "eu lavo as minhas mãos".

> Mas no caso do catalyst e do mojo e do dancer dá pra escrever a mesma
> coisa, baseado no mesmo conceito de mapear uma url pra uma subrotina,
> inclusive a sintaxe do dancer e do mojo também são similares, não tem
> nenhuma melhoria significativa, não tem nada que reduza a quantidade de
> código em uma ordem de grandeza e aumente a consistência e
> manutenibilidade da aplicação ao mesmo tempo. E se for só pra brincar de
> golfe, eu acho que o catalyst ainda ganha dos dois. Até entendo que
> talvez precise uns ajustes aqui e ali na sintaxe, e sempre vai precisar,
> mas, não se re-escreve um framework inteiro pra acrescentar melhorias
> que impactam uma área minúscula do framework. Eu escrevi o
> Catalyst::Lite como forma de demonstrar que não precisa escrever 30 mil
> linhas de código pra melhorar algo tão trivial quanto a sintaxe de
> declaração de dispatch de um framework web.

Esse ponto "trivial" pode ser importante pra muita gente. E pode ser a
diferença entre algo ganhar aceitação ou não. Se surgisse um novo
framework web com a mesma sintaxe do Catalyst, não ganharia
praticamente nenhum adepto, acredito eu. O Dancer traz a proposta de
uma sintaxe que parece ser mais moderna e aposta forte na integração
com o Plack, tenta se vender como o "cool kid on the block" (e, em
geral, tem conseguido). O Mojolicious também tem uma sintaxe mais
"moderna" mas me parece que foca em lutar contra o "dependency-hell"
(que pra mim nem é um problema, pra ser sincero, acho bem fácil e
rápido instalar módulos, mas tem gente que parece que não concorda) -
além de ser projeto do sri, o que traz algumas peculiaridades.

Eu acho que faz perfeito sentido os 3 existirem. É como falar que não
faz sentido existir vários estilos de metal diferentes, porque é tudo
"rock pesado" tocado com guitarras.

-Nilson