Diretrizes gerais de desenvolvimento para Mooodle
Autor: Badiu | Publicado: 2013-12-05T18:25:00-08:00

&nbsp;&nbsp;&nbsp; Assim como qualquer framework, o Moodle oferece um ambiente de desenvolvimento em que o programador deve seguir um&nbsp; conjunto de regras para implementar código que seja compatível ou reconhecidos pelo kernel do sistema.&nbsp; Segue algumas regras básicas.&nbsp;
1-&nbsp;&nbsp;&nbsp; Modularização - Para implementar uma nova funcionalidade ou alterar uma já existente sem modificar o código da distribuição padrão do Moodle, crie um novo&nbsp; módulo ou plugin. Para cada tipo de funcionalidade há um tipo de plugin do Moodle. Por exemplo, há plugin&nbsp; para cadastro/autenticação de usuário, matricula no curso, relatório de nota, relatório de curso etc.&nbsp; A implementação de cata tipo de plugin deve seguir uma regra para se integrar ao sistema do Moodle. A implementação do código fora da estrutura de modularização dificulta ou inviabiliza não só a portabilidade, como também a atualização do Moodle para versão mais recente sem perder o código que implementa as novas funcionalidades.&nbsp;
2-&nbsp;&nbsp;&nbsp; Padronização Nomes&nbsp; – O framework Moodle&nbsp; faz integração dos plugins através do nome.&nbsp; O nome da pasta do plugin é a chave de identificação do plugin no framework. Dois plugin do mesmo tipo não podem ter o mesmo nome, ou seja, não podem ficar na mesma pasta. Cada tipo de plugin tem um local específico que deve ser instalado. Por exemplo, os plugins de matrícula ficam na pasta MOODLE_DIR/enrol. Cada subpasta da pasta enrol representa um plugin. Cada tipo de plugin deve ter uma estrutura de arquivos, classes e funções específicas. Por exemplo, o plugin de matrícula da versão 1.9 deve ter um arquivo enrol.php. Nesse arquivo deve existir uma classe enrolment_plugin_NOME_PASTA_PLUGIN. O nome do plugin deve compor o nome da classe para evitar duplicação de nome da classe. Dentro dessa classe deve existir um conjunto de função já definidas. Desse modo, o framework carrega dinamicamente o plugin e a classe.&nbsp; Da mesma forma, as tabelas do banco de dados do plugin devem ter o&nbsp; prefixo do nome do plugin. Isso evita duplicação de nome da tabela. Por outro lado, facilita a identificação das tabelas.&nbsp;
3-&nbsp;&nbsp;&nbsp; Permissão&nbsp; - Para gerenciar as permissões de acesso as funcionalidade de um plugin, é necessário que todas as permissões do plugin sejam definidas no arquivo access.php. Na estrutura de arquivo padrão de qualquer plugin, o arquivo access.php deve ficar dentro da pasta bd. Esse arquivo é carregado automaticamente durante a instalação do plugin. O core do sistema lê as permissões definidas nesse arquivo e alimenta a tabela mdl_capabilities e mdl_role_capabilities.&nbsp;
4-&nbsp;&nbsp;&nbsp; Banco de dados – Para gerar a tabela do banco de dados automaticamente durante o processo de instalação de um plugin, é necessário definir a estrutura da tabela no arquivo install.xml. Esse arquivo deve ficar na pasta db do plugin. O core do moodle faz leitura desse arquivo durante o processo de instalação e gera&nbsp; a tabela do banco de dados.&nbsp;&nbsp;
5-&nbsp;&nbsp;&nbsp; Internacionalização de idioma – O core do framework Moodle gerencia o pacote de idioma de todos os plugins.&nbsp; Para isso, é necessário que todas as mensagens&nbsp; e textos do plugins&nbsp; sejam definidos no arquivo específico do pacato de idioma. Por padrão em qualquer plugin o pacote de idioma deve ficar na pasta lang. &nbsp;&nbsp;&nbsp; Seguir essas regras durante o processo de desenvolvimento para Moodle garante total compatibilidade e portabilidade do código. Por outro lado, a atualização não compromete a customização já feita desde que não haja incompatibilidade do core da versão recente em relação a versão anterior.&nbsp;&nbsp; Na contramão está o hacker do código que impacta a portabilidade&nbsp; e a atualização.