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