Contorna isso programando da maneira correta do Kohana. Kohana não é um CMS, também não é um sistema de Blog, é uma framework.
Admin deveria ser Application Blog outra Application Cada um com seu bootstrap carregando os modules que precisam pra funcionar. Você pode até criar um include em comum para os bootstrap terem um padrão pai. Mailmarket e Projetos eu não sei definir pq depende de como estão programados e os nomes não sugerem sua real aplicação, pra mim eles seriram modulos que poderiam ser extendidos por uma aplicação, onde a controladora e o view ficariam na aplicação. No bootstrap da aplicação vc seleciona os modulos que precisa usar pra dar certo. Cara tem muita coisa feita de maneira errada no github pra Kohana, maioria dos programadores não seguem o padrão de projeto do core do kohana, estendem e usam do jeito que quiserem. Isso é uma opção do programador fazer algo genérico ou não. Principalmente pq o padrão do Kohana torna em parte mais lento o desenvolvimento, porém muito mais seguro do que ficar criando aplicações completas com nome de module. O que o Jomla, Wordpress entre outros tem são plugins e não modulos. Evite utilizar modulo como plugin, são coisas diferentes. Quem tem pasta de plugin é o Rails do Ruby, dentro de um plugin vc pode ter módulos especificos ou extendios de dependencias, o namespace do Ruby permite isso, o do PHP não permitia (até inserirem o namespace do 5.3), porém o Kohana não implementou ainda namespace do PHP e módulos são módulos não são aplicações ou plugins, pelo menos deveriam. Agora, todo o padrão de projeto deve ser implementado conforme o projeto exige, tempo e nível de conhecimento da equipe permite. Equilibrando a eficiencia e eficacia dele, não adianta se ter algo perfeito que nunca será finalizado. Estude o que for melhor pro seu caso, e manda bala. O mais importante é estudar, leia o código do Kohana, veja como o core estende, implementa, reflete, etc os objetos. Ah, se tu for fazer os Applications como application mesmo e não como módulo, ficaria algo assim: index.php -> do teu application site bootstrap.php -> site admin/ admin/index.php -> application admin admin/bootstrap.php -> admin blog/ blog/index.php -> application blog blog/bootstrap.php -> blog modules/ modules/... system/ system/... No bootstrap de cada application tu escolhe os modules que ele vai precisar e define onde ta as constantes com pasta. Desta maneira se tu alterar algo no teu site, teu admin não vai parar de funcionar, nem teu blog e vice-versa pois não são dependentes. E você pode definir modelos como modulos em comum, onde altera pra um deles e todos vão utilizar com as novas regras. Boa sorte, Abraço, 2011/4/15 felipe moraes <[email protected]> > Está estruturado da seguinte forma ... > > application <- site > > modules/admin <- sistema admin do site > modules/mailmarket <- sistema de newsletter e emailmarketing > modules/projetos <- sistema gerenciador de projetos > modules/blog <- um modulo de sistema de blog já existente no github > > inclusive, no github tem até módulo de sistema CMS [com o sistema > totalmente funcional] > > urls exemplo: > > site.com/ <- application > site.com/admin <- sistema admin do site > site.com/mailmarket <- sistema modulo administrador de news e > emailmarketing > etc.. > > Estou estudando uma forma de implementar o módulo de dependência entre > módulos ..exemplo: > modules/admin e modules/mailmarket dependem do modules/auth estar > funcionando para funcionar tbm .. > > e por aí vai .. > > Uma coisa que me preocupa e tbm me motiva é o fato do kohana carregar > módulos mesmo quando não requisitado .. > > Se vc criar um módulo XXXX e lá tem uma classe com erro...quando você vai > acessar o site principal .. o kohana vai mostrar o erro do módulo .. > > pois no bootstrap ele está ativado e carregado. > > Apesar deste problema .. isso possibilita algumas coisas interessantes .. > :D > > já tinham verificado isso ? como contornaram ? > > > Em 15 de abril de 2011 19:54, GARTZ <[email protected]> escreveu: > > Cara eu arrumei um módulo chamado useradmin que extende auth inclusive e >> originalmente ele tem controller e view no módulo. >> >> No caso dele, não vejo problema, pois essas controllers são exemplos, se o >> cara não quiser usar (inclusive não uso na minha aplicação) é só >> sobrescrever e tocar o barco. >> >> No teu caso eu não entendi realmente o modelo da tua aplicação (modelo != >> modulo), por tanto não saberia o que indicar. >> >> Pessoalmente eu acredito na pratica de modulos genéricos (totalmente) onde >> o modelo seja com regras e métodos que se encaixem a qualquer aplicação que >> os use. Por fim você determina limites (se usuário logado ou não, vai poder >> fazer isso ou aquilo) na tua controladora e isso tu vais fazer na tua >> aplicação e não no modulo. >> >> Mas isso não é uma regra, tem que usar o bom senso. Unittest é um modulo >> que é quase uma apicação, tanto que tem tudo até controladora e view. No >> caso vc vai ver que ele total e completamente idependente do application que >> ele tiver rodando. >> >> -- > 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.
