[SP-pm] Validar session no Catalyst

[Eden Cardim]

>>>>> "Andre" == Andre Carneiro <andregarciacarneiro em gmail.com> writes:
    Andre> Humm, fiquei curioso. Que limitações? O que vc poderia estar
    Andre> tentando fazer que não dá pra fazer com o Catalyst?

    Andre> Se não for pedir muito, poderia falar mais sobre os problemas
    Andre> que vc não conseguiu resolver com o Catalyst?

Não que não dê pra fazer, mas precisa de workarounds e designs menos
elegantes. Um deles é o carregador de componentes, que carrega os
componentes (models, views, controllers) percorrendo o diretório de
componentes e carregando/instanciando na ordem em que o SO decide
percorrer o disco, em casos onde um componente depende do outro, isso
pode não dar problema em um sistema e ser problemático em outro, com o
mesmo código, isso confunde os desenvolvedores. Além disso, como não dá
pra saber qual componente vai ser carregado primeiro, você precisa fazer
um "use Model::Foo" dentro de Model::Bar antes poder usar o módulo, mas
mesmo assim, ele não vai ficar disponível via $c->model('Foo'), isso é
um problema recorrente em todos os frameworks que carregam componentes
de forma automática. A propósito, o loader do Mojo tem o mesmo
problema. Resolver esse problema é o projeto do André Walker no gsoc, a
solução, usando Bread::Board, vai dar mais flexibilidade ainda pro
sistema de carga de componentes.

Outro problema, que também existem nos outros frameworks, é que o
dispatcher precisa parsear a requisição inteira antes de poder fazer o
dispatch, então não dá pra casar com urls diferentes a depender da
lógica de tratamento daquela requisição específica. Por exemplo, se você
quer liberar um usuario pra fazer um GET na url /admin/users mas barrar
pra GET /admin/cds. Você precisa sair espalhando um monte de ifs no
código pra bloquear os lugares adequados, quando tem muitas regras
assim, é fácil uma escapar. Fazendo um match incremental, você pode
armazenar a lista de sub-paths adequados no user e simplificar a
lógica. No caso, com Web::Simple, que faz incremental, dá pra fazer algo
assim:

--8<---------------cut here---------------start------------->8---
sub (GET + /admin/...) {
    my($self) = @_;
    my $user = $self->login();
    return $user->actions;
}

package User::Admin::Users;

sub actions {
    sub (/users) {
       sub (/list) {
         # etc...
       },
       sub (/create) {
         # etc...
       }
    }
}

package User::Admin::CDS;

sub actions {
    sub (/cds) {
       sub (/list) {
         # etc...
       },
       sub (/find-track?:title=) {
         my($self, $title) = @_;
         # etc...
       }
    }
}
--8<---------------cut here---------------end--------------->8---

E aí o dispatcher já resolve as permissões pra você a depender da classe
de $user. Você também pode montar um objeto $user compondo várias roles
dinamicamente com moose. Observa que o dispatcher só sabe qual a próxima
string que precisa casar, depois que ele consome '/admin' da url,
executa o método e pega $user. Se em algum ponto não casar, ele já pode
abortar a requisição, mandar os pacotes pra /dev/null e economizar
alguns milisegundos porque não gasta processamento pra parsear o resto
da requisição.

ufa, tem outros problemas, mas... já tá grande o email.

-- 
   Eden Cardim       Need help with your Catalyst or DBIx::Class project?
  Code Monkey                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://blog.edencardim.com/            http://www.shadowcat.co.uk/servers/
http://twitter.com/#!/edenc