Version 18 (modified by pedroerp, 14 years ago) (diff) |
---|
Versão Experimental - Flumen
Em paralelo ao desenvolvimento normal do módulo workflow, encontra-se em construção uma nova versão experimental, com o objetivo de reestruturar o módulo e introduzir melhorias significativas. O codinome desta versão é "Flumen".
O código fonte está disponível na área sandbox do Svn, e está estruturado da seguinte maneira:
sandbox | + - workflow | + - trunk | + - branches | + ticket #
O ramo trunk é destinado para a versão em desenvolvimento consolidada, isto é, o código existente no trunk deve ser funcional, podendo ser baixado e executado, com o mínimo de problemas.
O ramo branches é destinado para as versões em desenvolvimento, associadas a tickets do Trac. Cada novo experimento deve estar registrado em um ticket associado ao milestone "SandBox - Workflow".
O ciclo de vida de uma implementação no Flumen deve ser:
- Criar um ticket no Trac para descrever e discutir a nova implementação;
- Associar o ticket ao milestone "SandBox - Workflow";
- Criar um branch a partir do trunk e nomeá-lo com o número do ticket;
- Desenvolver as modificações no branch e testar;
- Quando estiverem concluídas, fazer o merge com trunk e testar;
- Fechar o ticket.
Caso o assunto de um ticket seja de fácil implementação, é opcional criar o branch para ele, podendo a implementação ser feita diretamente no trunk.
Não é recomendado ter mais de um ticket por branch. É preferível ter sempre a associação 1:1 de um ticket ao seu próprio branch.
Caso alguma implementação no Flumem possa ser aproveitada de imediato no módulo oficial, nada impede que seja transferida, desde que bem testada e não comprometa o funcionamento do módulo e processos.
Neste link você pode acompanhar o andamento dos tickets associados a esta versão experimental.
Abaixo, segue uma lista de melhorias desejáveis para a nova versão.
Propostas para o Módulo
- Definir uma nova árvore de diretórios para o módulo que contemple:
- Isolar o código acessível pelo Expresso (inc);
- Separar o código interno do módulo (lib);
- Separar o código de terceiros (php e js);
- Prever local (custom) para o código das organizações: hooks, plugins, especializações de classes, templates.
- Revisar o código do engine
- Remover métodos desnecessários;
- Encapsular as classes e atributos, segundo orientação por objetos (private, public, protected);
- Remover o design pattern Observer;
- Transferir para o módulo as classes que são de estrutura dos processos e deixar no engine apenas as funcionalidades relativas ao andamento das instâncias;
- Eliminar a sobrecarga de métodos do engine que está sendo feita na pasta inc do workflow. Por exemplo a classe workflow_processomanager;
- Eliminar o parâmetro link do banco de dados passado na construção da classe;
- Documentar o engine com um diagrama de classes e um diagrama entidade-relacionamento;
- Verificar se é possível documentar o engine com algum diagrama comportamental.
- Criar uma nova factory estática para o workflow
- Fazer o registro das classes que podem ser utilizadas;
- Avaliar o design pattern registry e ver como pode ser aproveitado;
- Encapsular objetos do array $Globals;
- Criar um cache na factory;
- Avaliar como pode ser feito um cache de objetos que perdure após um recarregamento da página, por exemplo utilizando sessão ou memcache;
- Definir um hook para implementar o cache personalizado de um organização. Se inexistente, usa o padrão do workflow;
- Aproveitar esta factory também para os processos, e prover uma forma de isolar as classes que são do módulo. Uma possibilidade seria criar uma factory abstrata e uma especialização para o workflow e outra para os processos;
- Verificar se é possível utilizar o autoload para identicar a localização dos arquivos fontes;
- Reorganizar o código do workflow utilizando plugins
- Definir uma estrutura de plugins que possibilite a separação do núcleo do workflow e suas funcionalidades periféricas;
- Entende-se por núcleo do workflow toda a estrutura responsável pela execução de atividades, controle do fluxo dos processos, controle de plugins e segurança;
- Cada plugin deve ter um identificador único que será cadastrado no banco de dados e que possibilite a sua habilitação ou desabilitação;
- No banco de dados devem ser inseridos dados como: o identificador, localização do arquivo da controller, nome da classe e status;
- Os plugins devem estender uma classe geral que defina métodos padrão para registro, instanciação e execução daqueles;
- Em determinados lugares dentro do módulo devem ser definidos hooks. Ex. Menu lateral de administração, aba na interface de usuário, etc.;
- Deve-se criar uma estrutura padrão para os plugins que siga o design pattern MVC;
- Deve existir algum controle de acesso para liberar os plugins para usuários;
- Possibilitar aninhamento de plugins;
- Possibilitar a criação de plugin na área custom da organização.
- Definir uma estrutura de plugins que possibilite a separação do núcleo do workflow e suas funcionalidades periféricas;
- Pesquisar e implantar uma ferramenta para design dos fluxos dos processos
- Atualmente os processos são cadastrados através de formulários, onde o desenvolvedor informa as atividades, transições, perfis, etc. Depois pode exibir um gráfico do processo. A proposta é encontrar uma ferramenta que faça o contrário: desenhe o fluxo e este sirva de entrada para registrar a estrutura do processo. Possivelmente o fluxo será descrito em uma linguagem de definição que pode ser lida pelo módulo workflow, ou então a nova ferramenta poderia acessar diretamente o banco de dados;
- Reformular a interface administrativa para que as operações possam ser feitas sobre a imagem do processo. Por exemplo, clicando sobre ícone de uma atividade tem-se acesso às suas propriedades e perfis;
- Impedir que modificações sejam feitas no fluxo quando existirem instâncias dependentes das atividades.
- Implantar um gerador de código
- Com este novo recurso, quando o gráfico do processo estiver concluído, será gerado o código básico para que o processo funcione. Assim sendo, o desenvolvedor ficaria com a tarefa de preencher lacunas no código, como por exemplo os formulários e métodos associados aos botões.
- Criar um mecanismo autenticado para inclusão de instâncias
- Com esta funcionalidade, sistemas externos poderão iniciar instâncias no workflow, sem passar pelas atividades Start dos processos;
- Considerar o uso de web-service autenticado;
- Considerar a possibilidade de uso de certificado.
- Criar boletins para processos
- Implementar uma área, em cada processo, para divulgar as novidades, melhorias e correções. Isso é útil para os usuários acompanharem a evolução dos processos.
- Avaliar as bibliotedas de javascript utilizadas no Expresso e escolher aquelas que serão as oficiais
- Dentre as bibliotecas existentes, que sejam de mesma natureza, optar por uma delas e modificar o código do módulo.
- Substituir o conector Ajax
- Trocar o atual conector Ajax (connector.js / controller.php) usado na interface do módulo, pelo framework nanoAjax, que já é utilizado nos processos. Substituir todas as chamadas do antigo conector pelo novo.
- Criar um controle de tempo de execução para atividades
- Implementar uma nova funcionalidade para atividades em que possa ser definido um tempo máximo de permanência da mesma com o usuário que detém a posse;
- Criar um job genérico que rode diariamente e selecione as atividades que expiraram os prazos, e de alguma forma comunicar o usuário ou um administrador designado;
- Se ficar inviável criar o job, porque o atual modelo exige configuração do cron do servidor, criar ao menos um página que mostre o resultado das pesquisas com opção de envio de email;
- Verificar a possibilidade de gravar buscas no monitoramento por processo, e efetuar envio de email automático a partir do resultado da busca.
- Prover uma auditoria de queries executadas nas tabelas do módulo Workflow.
- Quando alguma alteração nos dados do processo for realizada, na interface de administração, registrar o evento em banco de dados para se ter um histórico dos acontecimentos. Por exemplo, ativação/desativação de processo, alteração de configuração, inclusão/exclusão de elementos, etc;
- Verificar a possibilidade de executar triggers nas tabelas do módulo Workflow, para logar a atividade sql. Cuidar para não impactar na performance geral do banco;
- Outra abordagem pode ser inserção de código nos principais eventos administrativos, para logar as modificações;
- Pensar em uma maneira de fazer um acompanhamento por processo, onde um usuário possa visualizar qualquer instância, e não somente as que detém a posse;
- Uma solução pode ser a criação de um perfil especial [Leitor] e associar os usuários que podem visualizar instâncias do processo;
- No menu 'mais ações' da instância, criar hooks para possibilitar inclusão de código a ser executado quando a ação for acionada;
- Por exemplo, ao abortar uma instância, realizar também alguma manutenção no banco de dados do processo;
- Modificar o template padrão de processos para:
- Definir um hook para personilizar o template de processos por organização;
- Criar parâmetros para incluir as bibliotecas de javascript.
- Implantar uma ferramenta de automação de testes e deploy
- Considerar a experiência do Serpro-BA com os softwares phpunit, phpdocumentor, codesniffer, ant, hudson (integração contínua);
- Verificar a possibilidade de expandir as funcionalidades do Processo de Transferência;
- Estudar uma maneira de realizar o deploy completo do processo, envolvendo o código fonte e a estrutura de atividades, transições e perfis.
- Executar o código do módulo sob tratamento de exceções (try/catch);
Propostas para o MVC
- Definir uma nova estrutura de diretórios para os processos
- Considerar a experiência do Serpro-BA;
- Analisar a estrutura de outros frameworks como o Cake e Simphony;
- Prever áreas para:
- Model-View-Controller;
- Ajax;
- Templates;
- Js;
- Imagens;
- Jobs;
- Classes de Negócio;
- Config;
- Facade (opcional);
- Dao;
- Serviços
- Log.
- Isolar os dados variáveis como log, documentação, compiled, smarty, graph, para facilitar a automação de deploy e a integração com IDEs;
- Substituir a função wf_include por factory.
- Criar um novo modelo de execução de atividades
- Suprimir o arquivo php da atividade;
- Dividir a atividade em model-view-controller
- Deverá existir um classe mãe para cada camada, com métodos para inicialização, finalização, cancelamento, execução, continuação de uma instância, execução de ajax, comunicação com o engine, etc;
- A classe da atividade deverá implementar os métodos que forem necessários;
- Criar uma nova classe run_activity, que será responsável por instanciar a classe controller da atividade e executá-la;
- Impedir que a controller tenha acesso aos atributos e métodos da run_activity;
- Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado;
- Testar se é seguro incluir o código da controller diretamente na run_activity;
- Impedir que a controller tenha acesso aos atributos e métodos da run_activity;
- Criar um mecanismo que impeça o código do usuário criar objetos das classes do módulo e do engine. Como sugestão poderia ser uma análise no call_back procurando a origem da instanciação;
- Acomodar os processamentos pré e pós execução das atividades (agente de correio) em outro local do código;
- Criar plugins para processos;
- Transformar a conexão mainframe da Celepar em um plugin;
- Tranformar a factory do processo em estática
- Instanciar os objetos hoje pré-carregados, sob demanda;
- Eliminar a código compilado;
- Pensar se é viável liberar para o processo gravar dados na sessão;
- Prover uma maneira do workflow diferenciar o código do mvc antigo e do novo e executar corretamente cada ambiente.
- Executar a atividade com tratamento de exceções (try/catch).
- Criar uma camada de visualização
- Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc;
- Prever inclusão da validação do componente;
- Implementar um componente container, que agrega componentes em uma mesma linha do template;
- Criar componente de ocultação;
- Criar um controle de acesso por componente, para ocultar elementos que não estejam disponíveis para um usuário;
- Prever também o encapsulamento dos plugins smarty criados para o workflow (select users, etc);
- Carregar no template os arquivos javascript indicados pelo desenvolvedor. Possibilitar associar funções javascript aos componentes;
- O objeto view deverá carregar os dados preparados na camada model e mesclar no template;
- A criação do objeto smarty ficará ao encargo da camada view;
- Criar uma função Js (goAjax) padrão para criar o objeto NanoController e adicionar a chamada virtual (addVirtualRequest);
- Simplificar os arquivos css e usar div ao invés de tabelas;
- Pensar na possibilidade de aproveitar os frameworks de css 960 ( http://960.gs) e blueprint ( http://www.blueprintcss.org) na camada de visualização.
- Tratamento e exibição de erros
- O submit fará uma chamada ao dispatch:
- O dispatch fará a verificação prévia de campos obrigatórios (1o. passo);
- Caso não tenha erros fará a validação dos componentes, via ajax (2o. passo);
- Caso não tenha erros irá chamar o método de validação em php, via ajax (3o. passo);
- O método de validação php terá um nome padrão e será responsável por validações de negócio;
- Caso existam erros na validação ajax, será polulado um array Js para exibição das mensagens no template (prever uma área para mensagens);
- Caso sem erros, será montado o array request na model e feita a submissão. Validar novamente pela model php;
- Existindo erros, estes serão adicionados a uma variável smarty, recarregado o template e as mensagens exibidas pela mesma função Js da validação ajax;
- Incluir no template padrão uma função Js para exibir os erros encontrados.
- O submit fará uma chamada ao dispatch:
- Camada Model
- Criar métodos para verificação de segurança sobre dados entrados pelo usuário: sqlinjection, xss;
- Avaliar o htmlpurify e as soluções já utilizadas na run_activity e personalizadas nos processos já desenvolvidos;
- Revisar e padronizar as classes utilitárias: tratamento de datas, expressões regulares, tipos de dados;
- Incluir tratamento de erros na classe wf_db. Atualmente o workflow delega esta ação para o desenvolvedor;
- Retornar o erro produzido pelo adodb ou o resultado da operação (resultset);
- Criar automação de relatório genérico com a classe fpdf;
- Criar métodos para verificação de segurança sobre dados entrados pelo usuário: sqlinjection, xss;
- Criar uma biblioteca Js para funções úteis para os processos que não existam nas biblioteca de terceiros acessíveis pelo workflow.
- Criar um local para definição das constantes do processo
- Utilizado para array de mensagens;
- Constantes operacionais;
- Schema de banco de dados;
- Qualquer outro parâmetro de configuração global do processso que seja necessário.
- Verificar as possibilidades: pode ser no arquivo shared.php, ou em um arquivo config do processo, ou ainda em uma nova aba na adminstração do processo;
- Padronizar os índices do array Requests com um prefixo, para facilitar a transferência entre as camadas;
- Criar uma camada para mapeamento objeto-relacional
- Considerar a experiência do Serpro-BA com o Propel.