maluco++<div><br></div><div>Salvo um artigo para o próximo equinócio :)<br><br><div class="gmail_quote">2011/10/7 Thiago Rondon <span dir="ltr"><<a href="mailto:thiago@aware.com.br">thiago@aware.com.br</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Fri, Oct 07, 2011 at 06:17:09PM -0300, Tiago Peczenyj wrote:<br>
> Nao querendo sair do assunto mais ja saindo.<br>
> Nao sei comec,ar um projeto com catalyst. Vejo o cookbook, acho maneiro,<br>
> mas parece que nao da liga no cerebro. Pode ser questao de tempo, talvez.<br>
> Mas o ciclo de vida de um request no catalyst ainda nao entendi, por<br>
> exemplo.<br>
<br>
Tiago,<br>
<br>
Acredito que tua dúvida é muito pertinente.<br>
<br>
E pensando nisto, em 2009 eu escrevi este tutorial em pt_BR sobre o Catalyst:<br>
<br>
<a href="https://github.com/maluco/catalyst-tutorial-ptbr/blob/master/catalyst.pod" target="_blank">https://github.com/maluco/catalyst-tutorial-ptbr/blob/master/catalyst.pod</a><br>
<br>
Ela contempla o uso do Catalyst, com um exemplo simples de um aplicativo de<br>
agenda telefonica.<br>
<br>
Bonus: Este exemplo ainda funciona.<br>
<br>
E sobre a requisição, é interessante dizer que a filosofia do Catalyst esta<br>
direcionado em oferecer uma flexibilidade grande para o desenvolvedor, facilitar<br>
o "plug" de várias "coisas" de forma simples. Resumindo: o que visualizo é que<br>
outros frameworks são mais simples de começar, porém tornam a vida do desenvolvedor<br>
extremamente dificeis depois do "ponto" que você começa a necessitar de<br>
funcionalidades diferentes, seja ela direcionado para escalar sua aplicação,<br>
se comunicar com um servidor web de forma diferente, ou até mesmo interagir<br>
com outros módulos já existentes.<br>
<br>
Bonus: Você não fica "amarrado", tirar seu aplicativo do Catalyst é tão<br>
simples, pois na realidade ele trata tudo de forma "orgânica", e você<br>
acaba depois de um determinado tempo, entendendo que isto faz muito sentido.<br>
<br>
ATENÇÃO: Isto não é uma defesa ao Catalyst, e sim a sua filosofia. É da mesma<br>
forma que eu defendo módulos do namespace "Cache::", "AnyEvent::" e etc.<br>
<br>
Muitos de nós, acabamos desenvolvendo na fase inicial do "relacionamento" com<br>
o framework, baseado apenas na simplicidade de uma sintaxe, e esquecendo que<br>
além de desenvolver um aplicativo web, precisamos testar, precisamos manter,<br>
tornar a vida de quem for manter simples. Isto significa, que na minha opinião<br>
"dividir" as tarefas sempre que possível, ou seja, o que é de responsabilidade<br>
do framework seja bem definido, o que é de responsabilidade do banco de dados é<br>
do ORM XPTO, o que é de responsabilidade por serializar as coisas são de modulos<br>
determinados, o que é de responsabilidade por efetuar cache, são dos módulos<br>
no namespace Cache::, enfim...<br>
<br>
Bonus: Na minha opinião, a arquitetura de desenvolvimento do Catalyst é tão<br>
"simples" e orientado ao objetivo de ser exatamente um framework web, que<br>
em muitos casos, alguns frameworks dizem que esta filosofia é limitada, ou<br>
seja, um framework poderia fazer mais, ele poderia até serializar seus dados,<br>
ele poderia até acessar o teu banco de dados, ele poderia até executar testes<br>
automaticamente, enfim...<br>
<br>
CONTRA: Dificulta o acesso por muitos desenvolvedores a tecnologia, pois<br>
exige uma curva de aprendizado maior, e além do aprendizado no framework, de<br>
vários outros aplicativos que estão ao redor do framework, e que vão completar<br>
ele. Um framework que oferece sintaxe simples, que faz muito mais do que ele<br>
se propõe, oferece uma maneira muito mais rápida no primeiro contato para<br>
resolver teus problemas de forma geral.<br>
<br>
PRÓ: Liberdade para o desenvolvedor, o framework web, sendo apenas um<br>
framework web, e nada mais do que isto, na prática significada de forma<br>
prática estabilidade e flexibilidade no mundo de "software-livre", ou seja<br>
'plugue' com o que você quiser, e há muito menos código para aprimorar.<br>
<br>
Bonus: É melhor testar 'tudo' junto, ou tudo separado ? Ou os dois ? O<br>
interessante do Catalyst, que você é orientado de certa forma a resolver<br>
seu problema fora do framework web, e isto vai te ajudar muito, quando<br>
você começar a elaborar testes, ou mesmo quiser trocar de framework web. ;-)<br>
<br>
Mas, depois de tudo isto, fica uma outra pergunta, o que significa ser<br>
melhor ? O que significa visualizar 'liga' no framework que vou utilizar ?<br>
<br>
Acredito que o Catalyst é uma boa escolha, quando você procura simplesmente<br>
um framework web.<br>
<br>
Se você procura um framework web, que faça mais do que a proposta dele, e<br>
que isto vai te oferecer facilidades iniciais para o teu desenvolvimento,<br>
o Catalyst pode ser para alguns, uma escolha 'dificil', devida a curva<br>
de aprendizado.<br>
<br>
E por isto, que em alguns tutoriais normalmente que descrevem, 'vejam<br>
qual o ciclo de requisição no meu framework':<br>
<br>
sub respondendo_requisicao: URL('/') {<br>
my $resposta = shift;<br>
return $resposta->html("Olá mundo, veja como sou simples") if $parametro eq 'html';<br>
return $resposta->json( mundo => 'sou simples') if $parametro eq 'json';<br>
}<br>
<br>
Teoricamente, isto é possivel de se fazer em qualquer framework, basta você<br>
efetuar o teu setup para isto, e aí o que muda o setup 'default' ou mesmo<br>
o esforço que foi realizado para simplificar a sintaxe.<br>
<br>
Atenção: Eu acredito que a sintaxe do Catalyst poderia ser melhor, como<br>
usuário do framework. Eu gostaria de ver um projeto "em cima" do Catalyst<br>
oferecendo uma sintaxe mais simples no geral.<br>
<br>
Porém, qual é o meu real ganho com isto ? O meu ganho é sintaxe, mas eu<br>
preciso saber o que o framework esta fazendo 'debaixo' dos panos. Eu posso<br>
ter problemas logo ali, que se eu não entender bem, o que ele esta fazendo<br>
é complicado, vou ter que estudar mais para debugar algo e etc. O interessante<br>
é que este framework já consuma tecnologias que uso em outros cenários, e<br>
não apenas para o meu framework, isto gera uma curva de aprendizado<br>
"pós-inicio de relacionamento" muito menor.<br>
<br>
Bonus: Aplicações web, estão cada vez mais complexas, cada vez mais extendendo<br>
ferramentas diversas, tecnologias distintas, ou seja, saber que minha<br>
solução faz só uma tarefa e trabalha bem em conjunto com outros, é baita<br>
duma vantagem.<br>
<br>
Veja, minha indagação, não é nem sintaxe agora, e sim o que o framework faz<br>
no 'ciclo de vida da requisição'. Pois bem, eu ainda não encontrei nenhum<br>
framework web que faça isto melhor que o Catalyst, pq ? Ele simplesmente<br>
não quer saber de nada, ele simplesmente quer 'rotear' as requisições entre<br>
a minha aplicação, os módulos já existentes para suas respectivas tarefas e<br>
o servidor web.<br>
<br>
Ou seja, o 'ciclo de vida da requisição' no Catalyst é tão simples de ser<br>
explicado, que dificulta na comparação com outros frameworks. Pois, ele<br>
não faz mais nada além do que dizer 'você vai para cá, você vai para lá',<br>
agora o que você vai fazer lá, ou cá, é de responsabilidade tua.<br>
<br>
O setup 'default' do Catalyst é o MVC, que ele cria uma estrutura de<br>
diretórios para oferecer esta arquitetura, que é um consenso na grande<br>
maioria dos desenvolvedores web, ou seja, quem 'responde' a requisição é<br>
o "Controller".<br>
<br>
No "Controller" nada mais temos do que :<br>
<br>
1. sub root : Args(0) PathPart('') ... {<br>
2. my ($self, $c) = @_;<br>
3. warn $c->request->user_agent;<br>
4. $c->response->headers->header( 'X-Foo' = 'Bar')<br>
5. }<br>
<br>
1. Estou declarando o "cá" ou o "lá".<br>
3. Estou buscando a informação da requisição já efetuada, o user agent.<br>
4. Estou setando um cabeçalho HTTP para resposta.<br>
<br>
Ou seja, nestas poucas linhas, eu estou setando quem responde por este<br>
"código", estou mostrando informações da requisição, e estou preparando<br>
a resposta.<br>
<br>
Veja uma coisa, tanto a requisição, como a resposta, são baseado nos<br>
módulos do namespace "HTTP::" para oferecer compatibilidade com diversos<br>
outros módulos que trabalhem com HTTP.<br>
<br>
Qual o papel além de um framework do que este ?<br>
<br>
Esta pergunta, pode levar você para um framework ou outro. Quem vai<br>
definir, são suas necessidades, se você quer uma sintaxe por exemplo<br>
que retorne JSON diretamente como resposta, você pode ter um cenário<br>
para distinguir dois frameworks:<br>
<br>
use JSON;<br>
sub foo {<br>
return JSON->encode(foo => 'bar');<br>
}<br>
<br>
Ou, ter:<br>
<br>
sub foo {<br>
return json(foo => 'bar');<br>
}<br>
<br>
O que é mais simples ? O segundo, claro. Mas, antes de falar de sintaxe<br>
precisamos saber o que é feito por baixo dos panos, e é por saber o que<br>
o Catalyst faz e não faz, que opto por ele, e hoje o entendimento da<br>
"vida requisição" dele é até 'muito simples' e me deixa muito confortavel<br>
e seguro de saber que ele utiliza módulos com a mesma filosofia que ele,<br>
ou seja, o próprio módulo JSON que esta disponível não só para este<br>
framework, assim para tantas outras soluções.<br>
<br>
Eu acredito que estes frameworks mais novos, que estão oferecendo uma<br>
vida mais simples, podem ensinar muito para o Catalyst em relação a<br>
"tração" de usuários-desenvolvedores. Assim como o Catalyst pode<br>
ensinar muito, em como "manter tudo" de forma mais estável e elegante<br>
em relação ao ecosistema da comunidade Perl, no caso em especifico.<br>
<br>
Enfim, não tenho a menor intenção de gerar um flame war em cima desta<br>
resposta, e sim de levantar questões que eu ainda não vi sendo debatidas<br>
aqui. Na minha opinião pessoal, precisamos valorizar projetos que<br>
estão fazendo bem para todos, e não só para ele. Afinal, como comentei<br>
aplicações web estão cada vez mais complexas, e cada vez mais vamos<br>
"tirar proveito" de ecosistemas paralelos de desenvolvimento.<br>
<br>
O tempo é cada vez mais precioso, e eu hoje quero saber sim o que<br>
esta "por traz" dos desenvolvimetos de projetos em geral, até por<br>
que isto me dá uma baita segurança como profissional, saber que as<br>
coisas dificilmente vão ser descontinuadas de uma hora para outra<br>
e eu ter uma porção de código que não será mais compativel com nada.<br>
<br>
Desculpe o e-mail longo. Se tiver alguma dúvida mais pontual, por<br>
favor envie.<br>
<div><div></div><div class="h5"><br>
Abs,<br>
-Thiago Rondon<br>
<br>
=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://noticiasglobal.com" target="_blank">http://noticiasglobal.com</a><br><br>"If you’ve never written anything thoughtful, then you’ve never had any difficult, important, or interesting thoughts. That’s the secret: people who don’t write, are people who don’t think."<br>
</div>