Uma opção que usei em casos semelhantes é a seguinte: - Classe Abstrata User - Classe Concreta User1 - Classe Concreta User2
Na abstrata ficam métodos que trazem dados dos pontos de flexibilização do sistema. Ex: Classe Abstrata - getButtons(): mixed a view receberia um objeto da classe User e chamaria o método getButtons para pegar os botóes necessários. Desvantagens: - Trabalho inicial um pouco maior - Risco da classe ter muitos métodos com o tempo (mas ainda acho melhor do que o código ter muitos ifs, e além do mais, a classe pode ser subdivida posteriormente) Vantagens: - Adicionar novos tipos de usuários vai ser batata.!!! - Você sempre sabe onde modificar dados específicos de um usuário. - É ótimo se existem dados dependentes do usuário em mais de um lugar pois a sua arquitetura já está pronta para receber os métodos. Conclusão Usamos na Meritt essa estratégia para apresentar páginas muito semelhantes, mas para diferentes localidades. E queríamos um jeito de poder adicionar novos tipos de localidades no futuro e tenho gostado bastante do resultado. Em 19 de outubro de 2012 14:42, Douglas J.A.M <[email protected]>escreveu: > Acho eu que se a diferença é bem pequena, não custa nada apenas um if na > view, isso até sobrecarregará menos o sistema. > Porém apenas ocultar o botão não impede de um hacking, lembre-se de tratar > na action que processa tal url também tal permissão. > > > Em 19 de outubro de 2012 14:38, Everton Zamignan Pabon > <[email protected]>escreveu: > > Olá pessoal, boa tarde. >> >> Estou trabalhando num sistema onde em meu escopo de autorização os >> usuários podem assumir os seguintes papeis: "Administrador" ou "Normal". >> (haverá mais papeis futuramente). >> Pelo perfil do sistema, as páginas (leia-se views) são praticamente >> iguais tanto para o Administrador como para o usuário Normal. >> Geralmente o Administrador tem apenas um ou dois botões a mais na View >> então eu uso a mesma View para ambos, exceto quando essa View for muito >> diferente/complexa. >> >> Acontece que a todo momento as Actions tem que ficar decidindo o que >> fazer de acordo com o papel do usuário. >> >> Essa minha introdução é pra perguntar se essa forma de trabalhar está >> correta ou >> eu devo criar Actions e Views (e até Controllers) distintas de acordo com >> a papel, não importando o fato de serem bem semelhantes. >> >> Agradeço qualquer opinião. >> >> -- >> Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana >> Php" dos Grupos do Google. >> Para postar neste grupo, envie um e-mail para [email protected] >> . >> Para cancelar a inscrição nesse grupo, envie um e-mail para >> [email protected]. >> Para obter mais opções, visite esse grupo em >> http://groups.google.com/group/kohana-php?hl=pt-BR. >> > > -- > Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana > Php" dos Grupos do Google. > Para postar neste grupo, envie um e-mail para [email protected]. > Para cancelar a inscrição nesse grupo, envie um e-mail para > [email protected]. > Para obter mais opções, visite esse grupo em > http://groups.google.com/group/kohana-php?hl=pt-BR. > -- Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana Php" dos Grupos do Google. Para postar neste grupo, envie um e-mail para [email protected]. Para cancelar a inscrição nesse grupo, envie um e-mail para [email protected]. Para obter mais opções, visite esse grupo em http://groups.google.com/group/kohana-php?hl=pt-BR.
