Sistema modular

[Google Grupos]

Ol� pessoal,
tenho algum tempo que desenvolvo com kohana 2/3, mas nunca me atentei
aos "modulos".

hoje me encontro em uma situa��o que:

todos os sites que crio possuem admin, e todos os admin que desenvolvo
tem o cadastro de usuarios do sistema, a mesma coisa para todos
sem tirar nem por mais nada. (claro, poderia ser um modulo de cadastro
de usuarios), certo ????

agora, caso eu venha a usar um modulo em todos os clientes, e
determinado cliente
precisar de um campo, por exemplo: perfil de usuario. tem como
usar/implementar somente para este cliente ???

fora os tutoriais que ensinam a criar, que j� achei alguns, fiquei na
duvida !!!
poderiam me ajudar !!! ????

Giovani

[felipe moraes]

GIOVANI, não entendi sua dúvida ..

você usa o Kohana 3 .. correto ?

Se você já usou o módulo userguide dele .. deve ter percebido que pode utilizar o módulo de forma independente do restante do sistema [uma sub-aplicação] .. correto ?

Aí você colocou clientes no meio da conversa ..

Você fala de um mesmo sistema com uso compartilhado entre vários clientes ?

Em 15 de abril de 2011 10:28, Google Grupos <ph...@dsinterativa.com.br> escreveu:

Olá pessoal,

tenho algum tempo que desenvolvo com kohana 2/3, mas nunca me atentei aos "modulos".

hoje me encontro em uma situação que:

todos os sites que crio possuem admin, e todos os admin que desenvolvo tem o cadastro de usuarios do sistema, a mesma coisa para todos
sem tirar nem por mais nada. (claro, poderia ser um modulo de cadastro de usuarios), certo ????

agora, caso eu venha a usar um modulo em todos os clientes, e determinado cliente
precisar de um campo, por exemplo: perfil de usuario. tem como usar/implementar somente para este cliente ???

fora os tutoriais que ensinam a criar, que já achei alguns, fiquei na duvida !!!

poderiam me ajudar !!! ????

Giovani

--
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 kohan...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para kohana-php+...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/kohana-php?hl=pt-BR.

--
http://felipebastosweb.com.br
http://twitter.com/felipebastosweb

[Beto]

Acho q das duas formas é possivel.

Primeiro, com uma instancia dedicada do FW. Se em cada projeto vc tem uma copia do Kohana, provavelmente vc tem uma copia de todos os modulos dele. Nesse caso vc teria seu modulo admin, e copiaria ele p todos os projetos que fosse ultilizar.

Se vc tem o kohana e seus modulos compartilhados para mais de um projeto, acho q vc pode fazer essas 'particularidades' sobrescrevendo o que for necessario dentro de application.  O lance do cascateamento dos arquivos do kohana ajuda muito nisso. Nao sei se vc conhece bem esse esquema mas:

core < modulo < application

ou seja tudo que vc fizer em application ( no caso onde é necessaria a particularidade) sobrescreverá do modulo, e do core. Dai vc sai extendendo as classes necessarias e pumba! 

N sei se consegui explicar bem, mas ... espero q sim :P

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/15 felipe moraes <feli...@gmail.com>

[Juarez Junior]

Gosto de Kohana por isto, qualquer particularidade, basta extender e pronto :)

Fiz isto para auto_load dele com integração do zend e namespaces.

Dentro do application:

class Kohana extends Kohana_Core 

[s]

2011/4/15 Beto <madeinn...@gmail.com>

--
Juarez Junior - juarez...@gmail.com
http://twitter.com/juareznjunior
http://juareznjunior.wordpress.com/

[Google Grupos]

corretissimo !!!!

eu crio um modulo de usuarios, e todas minhas apps pode usar este modulo !!!
agora se em determinado cliente(sistema) eu tiver que implementar apenas um campo "perfil de usuario", por exemplo !!
terei que desvincular o modulo ?? como eu deveria proceder ??? recriar o modulo apenas para o cliente ??? (claro, seria apenas mover a pasta para dentro da APP, acredito eu...rs)

Att,
Giovanni Donda

[Beto]

vc sobrescreve o q for necessario na sua aplicacao.

[]s

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/15 Google Grupos <ph...@dsinterativa.com.br>

[Juarez Junior]

Não esquecer de deixar o comportamento normal :)

2011/4/15 Beto <madeinn...@gmail.com>

--

[felipe moraes]

Como o Beto falou...

Se vc tem o kohana e seus modulos compartilhados para mais de um projeto, acho q vc pode fazer essas 'particularidades' sobrescrevendo o que for necessario dentro de application.  

Acho que por sobrescrever .. ele está falando

copiar a pasta modules para o mesmo local onde está a application ..

- kohana/system

- kohana/modules

- cliente/application

- cliente/modules

aí no index.php do cliente .. vc coloca para usar o modules da pasta cliente dele ao invés do modules global usados por outros clientes

vc altera esse modulo especifico e ele não influencia os demais

[felipe moraes]

opa .. corrigindo ..

o sobrescrever na applicacao é uma idéia legal tbm .. caso a alteração seja pequena .. mas acho que a alteração que falou tem mais haver com views do que com controllers e models ..

a minha sugestão pode ser viável tbm

vai depender de como vc programa

[Beto]

vc pode ter tbm um modulo especifico de upgrade , n sei se seria legal mais ...

tipo :

application/

    modules/

        usuarios-cliente-x

modules/

    usuarios/

dai vc carrega o modulo usuarios-cliente-x depois do usuarios, e ele sobrescreveria o usuarios apenas no q vc deseja. Porém como se trata de uma particularidade de app eu n vejo problemas de sobrescrever nela mesmo.

enfim, como dizem .. "Fica a gosto do freguês" kkk

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/15 felipe moraes <feli...@gmail.com>

[Google Grupos]

vou mudar apenas questões no layout (view) acrescentando e diminuindo campos nos formularios,
mas sempre terei a base essencial para todos nos modulos.

preciso ver como fazer essa integração, a principio, somente nas views....

acho que é isso neh !!!

Abraços,
Giovani

[felipe moraes]

pelo que imaginei ..

acrescentar ou retirar um campo vai impactar mais na view ..

mas, se for um campo combo [selectbox] vc vai precisar alterar o controller do módulo tbm ..

ainda tem o caso do save ..

se vc mandar o $_POST direto para o módulo .. não altera nada .. mas se mandar os atributos .. individualmente .. terá mais impactos ..

$objeto->save($_POST); //nem recordo se o kohana trabalha assim :D mas tem algo semelhante

$objeto->atributonovo = $_POST['atributonovo'];

$objeto->save(); //que era como fazia mas vou começar a rever este caso

depende de vc - experimente todas as possibilidades sugeridas :D

[felipe moraes]

Como já foram apontadas várias alternativas ..

Vou aproveitar para colocar minha dúvida tbm .. já que o título é o mesmo :D

------------------------------------------------------------------------------------------------------------------

Um sistema .. tem suas características básicas .. mas sempre queremos acrescentar novas funcionalidades.

Digamos que vou acrescentar a parte administrativa .. ou um gerenciador de newsletter .. ou outras subaplicações ... que não estão, exatamente, no foco da aplicação principal ..

Vocês fariam tais recursos como módulos [módulo de sistema - em modules] .. ou criariam rotas na aplicação e colocariam como subdiretorios de controllers e models ?

Pergunto isso por que o kohana não distingue módulo de framework, de módulo de sistema ..

Pensando como fábrica de software .. seria interessante ter como modules e reaproveitar, ou habilitar/desabilitar .. o que pensam sobre isso ?

[Google Grupos]

então, é a minha situação !!!

tenho um modulo "central" para gerenciamento de usuarios da administração
todos meus clientes usam o mesmo modulo.

meu problema foi estender para um cliente, algumas modificações neste modulo.

acredito que um modulo seria melhor que subpastas no app do cliente.

Att,

Giovani

[Beto]

vc pode ter modulos 'cliente' basta informar onde o kohana deve carregar este modulo.

por exemplo, no bootstrap.php :

Kohana::modules(array(

'cache'      => MODPATH.'cache',                    // Modulo compartilhado entre todos

'cliente'      => APPPATH.'modules/cliente',      // Modulo apenas do cliente

nesse caso o modulo 'apenas do cliente' estaria em:

ROOT/application/modules/cliente

e o restante normalmente em 

ROOT/modules/

saca ?

[]s

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/15 Google Grupos <ph...@dsinterativa.com.br>

então, é a minha situação !!!

[Sudeste Hosting]

Pegando carona no post, essa caminho para o Modulo acendeu uma ideia aqui para um projeto,

Posso usar por exemplo:

'cliente'      => '/home/cliente/public_html/tema',      // modulo tema para o site

Será que funciona?

A flexibilidade é incrível,
e tem gente que vai deixar de usar http://aguimaraes.org/2011/04/abandonando-o-kohana/

 rrsrsrsr

Atenciosamente,
Bernardo Sepulveda de Castro
------- ------- ------- -------- -------- --------
Sudeste Hosting...
Ideias e Soluções Web
www.sudestehosting.com.br
(21)3305-3105

[Marcelo Rodrigo]

Sabe que eu nunca vi esse cara aqui na lista?

Ainda assim, gostei muito do artigo dele.

Atenciosamente,

Marcelo Rodrigo
http://marcelorodrigo.com

[GARTZ]

Discordo totalmente da matéria.

Quem vive no passado é museum, pega o Symfony cheio de publicações antigas e migre um sistema da versão 1.0 pra atual. É praticamente impossível, quando uma boa implementação de Kohana, por utilizar muito menos tipagem se torna uma tarefa simples de ser executada.

Claro tudo depende te um bom entendimento de namespace do Kohana e outras coisas. Claro que um programador que nem entende conceito de modulos, singleton, factory, reflection não vai conseguir tirar o melhor do Kohana. Mas vc pode pegar estagiários dedicados ao estudo e doutrina-los a trabalhar com Kohana de forma eficiente e limpa.

Se vc for um pouco além, o fato do kohana se aproveitar sempre das últimas atualizações do PHP e melhorar sua metodologia constantemente, permite que os programadores com menos código obtenham resultados muito melhores.

Sim espero que a versão 3.2 do Kohana mate de vez todas propriedades públicas, principalmente do ORM, que vai ser uma grande melhoria no namespace dele. E uma grande confusão pros desenvolvedores inexperientes e projetos mal feitos.

Por fim, quem está insatisfeito com o guide do Kohana, pare de fazer blogs e espalhar a informação de jeito desorganizado, pega o github, faz um fork do Kohana-Core incrementa o Guide e faz um pull request. Você irá ajudar toda comunidade e seu trabalho irá atingir muito mais gente do que uma matéria de blog.

O espirito OpenSource do Kohana é maravilhoso, façam bom uso! :)

PS: A framework está sempre em mudanças, lado ruim é que as vezes aparece bug quando não tem ainda teste unitário, lado bom o namespace do Kohana permite que vc estenda a classe que você quiser e faça um overload para corrigir o seu problema de forma simples e eficiente.

Abraço,

2011/4/15 Marcelo Rodrigo <mrod...@gmail.com>

[Beto]

Tbm achei a maioria dos argumentos dele sem fundamento ... 

layout do site oficial ??? Nome ??? 

cada um, com seu cada um!

[]s

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/15 GARTZ <ga...@l6.com.br>

[felipe moraes]

Todos os argumentos são baseados no kohana 2.

E o pior de tudo, ele não vende o produto .. ele vende o framework .. mal vendedor .. prejuízos :D

fiquei até surpreso com os links de módulos que o pessoal postou essa semana .. tem módulos kohana 3 para tudo que vc imaginar :D

é só ir no github :D

http://felipebastosweb.com.br
http://twitter.com/felipebastosweb

[GARTZ]

Kohana 3 é fantastico! Inclusive, se estiver insatisfeito com as facilidades vc pode simplismente adicionar o autoload de outra framework nele, e colocar umas correntinhas estilo Zend, Symfony, etc só pra deixar sua applicação mais hierarquicamente amarrada e o problema é seu, mas que é fantastico o fato de que vc pode fazer esse tipo de coisa, isso é inquestionavel.

2011/4/15 felipe moraes <feli...@gmail.com>

[Marcelo Rodrigo]

Eu nem vou perder tempo dizendo que sou um grande evangelizador e defensor do Kohana, uso ele basicamente em todos os projetos novos :)

Mas, gostei do artigo dele porque ele soube mostrar os defeitos do framework, sim ... ele tem defeitos.

Atualizações rápidas são boas porque fazem o produto melhorar.

São ruins porque o upgrade não é tão easy quanto em outras plataformas. Eu particularmente adoro a velocidade de desenvolvimento do Kohana.

Não concordo com todos os pretextos do cara, mas ainda assim gostei do artigo dele.

Parte porque é #fail e parte porque o cara teve coragem de publicar :)

Nem sempre o Kohana é a melhor alternativa, eu gosto de usar sempre a melhor alternativa conforme o projeto, e não conforme minha preferência pessoal.

Atenciosamente,

Marcelo Rodrigo
http://marcelorodrigo.com

[Vinicius Rezende]

Eu sempre entendi que

app > pasta para coisas especificas da aplicação
modulos > opcionais ou 3rd party
system > genéricos(tipo esse seu modulo de usuarios/painel adm)

2011/4/15 GARTZ <ga...@l6.com.br>

[Sudeste Hosting]

Meu conceito é diferente na System, aprendi que você não deve mexer,
e nem em:
app > log
app > cache

[Beto]

tbm nao costumo alterar nada na system. se for necessario o cara extende e tudo de boa1}

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/15 Sudeste Hosting <bs.c...@gmail.com>

[GARTZ]

Olha, quem trabalha com GIT fica bem claro

system é submodule de kohana-core, se tu for alterar é algo que vc quer inserir na framework em si, então vc tem que fazer um fork do kohana-core pra isso.

Em outras palavras, não altere system, jamais!

modules são modulos genéricos, podem servir pra sua aplicação atual, pra outras aplicações que vc esteja fazendo, seja 3th ou não.

Application, é sua aplicação, na realidade vc pode ter mais de uma aplicação, pro exemplo:

www.minha_aplicação.com.br = pasta pública que carrega bootstrap do application/minha_aplicação
admin.minha_aplicação.com.br = pasta pública que carrega bootstrap do application/admin_minha_aplicação

Isso é, com o mesmo system, e modules, tu pode ter várias aplicações diferentes que tem permissões e ações distintas, até mesmo nível de segurança distintos.

Por isso modules tem que ser genérico tal qual system. Controller se faz sempre na aplicação, tu pode colocar no teu modules um exemplo, mas é bom deixa-lo possível de ser extendido, mas não extendido por padrão.

Kohana é simples, só entender o namespace dele que a vida fica sem stress.

Abraço,

2011/4/15 Beto <madeinn...@gmail.com>

[Vinicius Rezende]

O.I.C.
My bad :3

2011/4/15 GARTZ <ga...@l6.com.br>

[Google Grupos]

ok,
então me ajuda:

um modulo generico, chamada cadastro de produto.

sendo generico, ele atende 2 dos meus clientes !!!
os outros 2 precisam variar uma informação, IMPOSTOS.

no caso, devo criar dentro do APP, sem mecher nos modulos, algum controlador que possa extender o view padrão/acrescentando a informação desejada !!????

fui claro ???
obrigado,
Giovanni Donda

[Beto]

Cara se vc so precisa sobrescrever a antiga view, adicionando um outro padrao, na application vc poe a nova view e ele vai considerar a da application pq tá no topo da pilha.

agora como foi dito antes, dependendo de como vc esses parametros no objeto talvez seja necessario mudar tbm o controlador.

[Marcelo Rodrigo]

Para entender melhor o cascateamento de arquivos e ordem de loading no framework, isso vai te ajudar:

http://kohanaframework.org/3.0/guide/kohana/files

Atenciosamente,

Marcelo Rodrigo
http://marcelorodrigo.com

[felipe moraes]

Bom ..

Apesar de ter o conhecimento, eu fiz a pergunta por que:

1. Primeiro, um cara do grupo fez um módulo Admin que extende Auth e usa como aplicação gerenciadora de permissões de usuário e a galera tocou fogo nele [semana passada - aqui no grupo :D]. E eu, queria ter certeza que a abordagem dele estava correta, embora a maioria fosse contra a idéia :D
2. Estou tentado a usar módulo como aplicação .. O userguide é um exemplo de que isso é adequado fazer. Inclusive, já comecei a fazer o módulo admin de toda a aplicação¹, e o módulo mailmarketing ... para colocar no meu site e outras aplicações que estou desenvolvendo do zero com kohana.
3. E o kohana usa módulos como bibliotecas, é o caso do ORM, database, PDFView, etc.

aplicação¹ - No kohana, por aplicação, entendo que seja a pasta application e todos os módulos que funcionam da mesma forma como a pasta aplication. Todo o sistema Modularizado [separado por módulos], não apenas a pasta application.

O próprio Codeigniter, na sua forma modular, faz a mesma coisa. E os plugins do Wordpress, etc .. quem já instalou o BuddyPress e o WP-Commerce, ou plugins mais simples, já viu os diferentes comportamentos que um plugin WP pode ter.

Resumindo: cheguei a conclusão de que .. usar módulo como aplicação é correto :D Por que, neste caso, é um módulo do sistema, e não apenas um módulo do framework.

E nada impede de separar os 2 tipos de módulo na pasta modules. Varia de gosto para gosto.

[GARTZ]

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.

E assim vai.

Pensa no básico da orientação a objeto, se tua aplicação for o CARRO, ou outra aplicação for a MOTO, teu System vai ser a FABRICA e teus módulos vão ser: MOTOR, PNEU, CHASIS, VIDRO, PARABRISA, etc.

Repare que para CARRO vc vai usar PNEU de um jeito e MOTOR de outro, já na tua MOTO se vai usar as mesmas coisas só que de jeito diferente do CARRO.

Tanto um quanto outro dependem de FABRICA, mas tua moto não depende de PARABRISA, por tanto na tua aplicação MOTO se não vai adicionar PARABRISA ao bootstrap.

Modulos podem ser interdependentes, mas cuidado com isso, o namespace do kohana atual não utiliza o namespace do PHP por tanto não da pra criar submodulo de modulo que pode gerar uma mega confusão na sua aplicação.

Exemplo: PNEU depende de RODA (pode estender a classe, ser um singleton ou um factory que utiliza-a, só depende do caso)

Boa sorte :)

2011/4/15 felipe moraes <feli...@gmail.com>

[felipe moraes]

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 ?

[GARTZ]

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 <feli...@gmail.com>

[felipe moraes]

GARTZ

Obrigado pela participação .. e concordo com tudo que disse .. é assim que eu [ou todos] programo[am]

A idéia é expandir essa verificação de dependência .. da forma como a ISO 17799 [Desenvolvimento de Software] sugere .. e não deve existir nada igual em PHP.

Como os módulos do Kohana possuem a mesma estrutura de aplicação .. a idéia era reaproveitar algumas coisas e expandir o restante :D

Mas o autoloading ajuda e atrapalha com relação as dependências ..quando se pensa em performance.

O chato seria eu provar que isso é inviável em PHP :D

Vou amadurecer a idéia .. depois volto :D

[Beto]

Se eu nao estiver enganado ja vi por ai algo com relacao isso, dependencia de modulos. Mas agora nao lembro onde, e tbm nao sei se tá implementado da melhor forma possivel. Dá uma googlada aê quem sabe n acha algo.

[]s

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Luiz Alberto S. Ribeiro [ Beto ]
@madeinnordeste

http://beto.euqueroserummacaco.com

2011/4/16 felipe moraes <feli...@gmail.com>

--