Changes between Version 20 and Version 21 of WF/versaoexperimental


Ignore:
Timestamp:
05/11/10 16:27:17 (14 years ago)
Author:
viani
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WF/versaoexperimental

    v20 v21  
    11= Versão Experimental - Flumen = 
    22 
    3 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". 
     3Em 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. 
     4 
     5O codinome desta versão é "Flumen". 
    46 
    57O código fonte está disponível na área [browser:sandbox/workflow sandbox do Svn], e está estruturado da seguinte maneira: 
     
    3638Caso 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. 
    3739 
    38 [http://trac.expressolivre.org/query?group=milestone&milestone=Sandbox+-+Workflow&desc=1&order=id&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version Neste link] você pode acompanhar o andamento dos tickets associados a esta versão experimental. 
     40== Maiores Informações == 
    3941 
    40 Abaixo, segue uma lista de melhorias desejáveis para a nova versão. 
    41  
    42 == Propostas para o Módulo == 
    43  
    44  * Definir uma nova árvore de diretórios para o módulo que contemple: 
    45   * Isolar o código acessível pelo Expresso (inc); 
    46   * Separar o código interno do módulo (lib); 
    47   * Separar o código de terceiros (php e js); 
    48   * Prever local (custom) para o código das organizações: hooks, plugins, especializações de classes, templates. 
    49  
    50  * Revisar o código do engine 
    51   * Remover métodos desnecessários; 
    52   * Encapsular as classes e atributos, segundo orientação por objetos (private, public, protected); 
    53   * Remover o design pattern Observer; 
    54   * 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; 
    55   * Eliminar a sobrecarga de métodos do engine que está sendo feita na pasta inc do workflow. Por exemplo a classe workflow_processomanager; 
    56   * Eliminar o parâmetro link do banco de dados passado na construção da classe; 
    57   * Documentar o engine com um diagrama de classes e um diagrama entidade-relacionamento; 
    58   * Verificar se é possível documentar o engine com algum diagrama comportamental. 
    59  
    60  * Criar uma nova factory estática para o workflow 
    61   * Fazer o registro das classes que podem ser utilizadas; 
    62   * Avaliar o design pattern registry e ver como pode ser aproveitado; 
    63   * Encapsular objetos do array $Globals; 
    64   * Criar um cache na factory; 
    65    * 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; 
    66    * Definir um hook para implementar o cache personalizado de um organização. Se inexistente, usa o padrão do workflow; 
    67   * 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; 
    68   * Verificar se é possível utilizar o autoload para identicar a localização dos arquivos fontes; 
    69  
    70  * Reorganizar o código do workflow utilizando plugins 
    71   * Definir uma estrutura de plugins que possibilite a separação do núcleo do workflow e suas funcionalidades periféricas; 
    72    * 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; 
    73   * Cada plugin deve ter um identificador único que será cadastrado no banco de dados e que possibilite a sua habilitação ou desabilitação; 
    74   * No banco de dados devem ser inseridos dados como: o identificador, localização do arquivo da controller, nome da classe e status; 
    75   * Os plugins devem estender uma classe geral que defina métodos padrão para registro, instanciação e execução daqueles; 
    76   * Em determinados lugares dentro do módulo devem ser definidos hooks. Ex. Menu lateral de administração, aba na interface de usuário, etc.; 
    77   * Deve-se criar uma estrutura padrão para os plugins que siga o design pattern MVC; 
    78   * Deve existir algum controle de acesso para liberar os plugins para usuários; 
    79   * Possibilitar aninhamento de plugins; 
    80   * Possibilitar a criação de plugin na área custom da organização.    
    81                  
    82  * Pesquisar e implantar uma ferramenta para design dos fluxos dos processos 
    83   * 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; 
    84   * 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; 
    85   * Impedir que modificações sejam feitas no fluxo quando existirem instâncias dependentes das atividades. 
    86          
    87  * Implantar um gerador de código 
    88   * 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. 
    89  
    90  * Criar um mecanismo autenticado para inclusão de instâncias 
    91   * Com esta funcionalidade, sistemas externos poderão iniciar instâncias no workflow, sem passar pelas atividades Start dos processos; 
    92   * Considerar o uso de web-service autenticado; 
    93   * Considerar a possibilidade de uso de certificado. 
    94          
    95  * Criar boletins para processos 
    96   * 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. 
    97  
    98  * Avaliar as bibliotedas de javascript utilizadas no Expresso e escolher aquelas que serão as oficiais 
    99   * Dentre as bibliotecas existentes, que sejam de mesma natureza, optar por uma delas e modificar o código do módulo. 
    100  
    101  * Substituir o conector Ajax 
    102   * 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. 
    103  
    104  * Criar um controle de tempo de execução para atividades 
    105   * 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; 
    106   * 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; 
    107   * 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; 
    108   * Verificar a possibilidade de gravar buscas no monitoramento por processo, e efetuar envio de email automático a partir do resultado da busca. 
    109          
    110  * Prover uma auditoria de queries executadas nas tabelas do módulo Workflow. 
    111   * 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; 
    112   * 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; 
    113   * Outra abordagem pode ser inserção de código nos principais eventos administrativos, para logar as modificações; 
    114  
    115  * 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; 
    116   * 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; 
    117  
    118  * 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; 
    119   * Por exemplo, ao abortar uma instância, realizar também alguma manutenção no banco de dados do processo;  
    120  
    121  * Modificar o template padrão de processos para: 
    122   * Definir um hook para personilizar o template de processos por organização; 
    123   * Criar parâmetros para incluir as bibliotecas de javascript. 
    124  
    125  * Implantar uma ferramenta de automação de testes e deploy 
    126   * Considerar a experiência do Serpro-BA com os softwares phpunit, phpdocumentor, codesniffer, ant, hudson (integração contínua); 
    127   * Verificar a possibilidade de expandir as funcionalidades do Processo de Transferência; 
    128    * Estudar uma maneira de realizar o deploy completo do processo, envolvendo o código fonte e a estrutura de atividades, transições e perfis. 
    129  
    130  * Executar o código do módulo sob tratamento de exceções (try/catch); 
    131  
    132 == Propostas para o MVC == 
    133  
    134  * Definir uma nova estrutura de diretórios para os processos 
    135   * Considerar a experiência do Serpro-BA; 
    136   * Analisar a estrutura de outros frameworks como o Cake e Simphony; 
    137   * Prever áreas para: 
    138    * Model-View-Controller; 
    139    * Ajax; 
    140    * Templates; 
    141    * Js; 
    142    * Imagens; 
    143    * Jobs; 
    144    * Classes de Negócio; 
    145    * Config; 
    146    * Facade (opcional); 
    147    * Dao; 
    148    * Serviços 
    149    * Log. 
    150   * 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; 
    151   * Substituir a função wf_include por factory. 
    152  
    153  * Criar um novo modelo de execução de atividades 
    154   * Suprimir o arquivo php da atividade; 
    155   * Dividir a atividade em model-view-controller 
    156    * 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; 
    157    * A classe da atividade deverá implementar os métodos que forem necessários; 
    158   * Criar uma nova classe run_activity, que será responsável por instanciar a classe controller da atividade e executá-la; 
    159    * Impedir que a controller tenha acesso aos atributos e métodos da run_activity; 
    160     * Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado; 
    161     * Testar se é seguro incluir o código da controller diretamente na run_activity; 
    162   * 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; 
    163   * Acomodar os processamentos pré e pós execução das atividades (agente de correio) em outro local do código; 
    164    * Criar plugins para processos; 
    165    * Transformar a conexão mainframe da Celepar em um plugin; 
    166   * Tranformar a factory do processo em estática 
    167    * Instanciar os objetos hoje pré-carregados, sob demanda; 
    168   * Eliminar a código compilado; 
    169   * Pensar se é viável liberar para o processo gravar dados na sessão; 
    170   * Prover uma maneira do workflow diferenciar o código do mvc antigo e do novo e executar corretamente cada ambiente. 
    171   * Executar a atividade com tratamento de exceções (try/catch). 
    172  
    173  * Criar uma camada de visualização 
    174   * Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc; 
    175   * Prever inclusão da validação do componente; 
    176   * Implementar um componente container, que agrega componentes em uma mesma linha do template; 
    177   * Criar componente de ocultação; 
    178   * Criar um controle de acesso por componente, para ocultar elementos que não estejam disponíveis para um usuário; 
    179   * Prever também o encapsulamento dos plugins smarty criados para o workflow (select users, etc); 
    180   * Carregar no template os arquivos javascript indicados pelo desenvolvedor. Possibilitar associar funções javascript aos componentes; 
    181   * O objeto view deverá carregar os dados preparados na camada model e mesclar no template; 
    182   * A criação do objeto smarty ficará ao encargo da camada view; 
    183   * Criar uma função Js (goAjax) padrão para criar o objeto !NanoController e adicionar a chamada virtual (addVirtualRequest); 
    184   * Simplificar os arquivos css e usar div ao invés de tabelas; 
    185   * Pensar na possibilidade de aproveitar os frameworks de css 960 ( http://960.gs) e blueprint ( http://www.blueprintcss.org) na camada de visualização.  
    186  
    187  * Tratamento e exibição de erros 
    188   * O submit fará uma chamada ao dispatch: 
    189    * O dispatch fará a verificação prévia de campos obrigatórios (1o. passo); 
    190    * Caso não tenha erros fará a validação dos componentes, via ajax (2o. passo); 
    191    * Caso não tenha erros irá chamar o método de validação em php, via ajax (3o. passo); 
    192   * O método de validação php terá um nome padrão e será responsável por validações de negócio; 
    193   * Caso existam erros na validação ajax, será polulado um array Js para exibição das mensagens no template (prever uma área para mensagens); 
    194   * Caso sem erros, será montado o array request na model e feita a submissão. Validar novamente pela model php; 
    195   * 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; 
    196   * Incluir no template padrão uma função Js para exibir os erros encontrados. 
    197  
    198  * Camada Model 
    199   * Criar métodos para verificação de segurança sobre dados entrados pelo usuário: sqlinjection, xss; 
    200    * Avaliar o htmlpurify e as soluções já utilizadas na run_activity e personalizadas nos processos já desenvolvidos; 
    201   * Revisar e padronizar as classes utilitárias: tratamento de datas, expressões regulares, tipos de dados; 
    202   * Incluir tratamento de erros na classe wf_db. Atualmente o workflow delega esta ação para o desenvolvedor; 
    203    * Retornar o erro produzido pelo adodb ou o resultado da operação (resultset); 
    204   * Criar automação de relatório genérico com a classe fpdf;  
    205  
    206  * Criar uma biblioteca Js para funções úteis para os processos que não existam nas biblioteca de terceiros acessíveis pelo workflow. 
    207  
    208  * Criar um local para definição das constantes do processo 
    209   * Utilizado para array de mensagens; 
    210   * Constantes operacionais; 
    211   * Schema de banco de dados; 
    212   * Qualquer outro parâmetro de configuração global do processso que seja necessário. 
    213   * 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; 
    214  
    215  * Padronizar os índices do array Requests com um prefixo, para facilitar a transferência entre as camadas; 
    216  
    217  * Criar uma camada para mapeamento objeto-relacional 
    218   * Considerar a experiência do Serpro-BA com o Propel. 
    219  
    220 == Utilizando branches == 
    221  
    222 Como descrito acima, tickets que exijam grandes modificações devem ser implementados em branches separados, ao invés de utilizar diretamente o trunk. O primeiro passo é criar um novo branch: 
    223 {{{ 
    224   svn copy https://svn.expressolivre.org/sandbox/workflow/trunk \ 
    225            https://svn.expressolivre.org/sandbox/workflow/branches/1001 \ 
    226            -m "Ticket #1001 - Criando novo branch para implementação do ticket." 
    227 }}} 
    228 O comando '''svn copy''' é utilizado para a criação de branches. Na forma que é mostrado acima, este comando não precisa ser executado a partir de um repositório svn, todo procedimento é realizado no servidor. O primeiro parâmetro é o branch de origem, de onde serão copiados os dados. Os branches criados para os tickets da versão experimental do Workflow devem sempre utilizar o repositório /sandbox/workflow/trunk como origem. O segundo parâmetro especifica o endereço do novo branch. O novo branch deve seguir o padrão /sandbox/workflow/branches/{#ticket}. Já o terceiro parâmetro, opcional e especificado pela opção ''-m'', especifica a mensagem do commit que criará o novo branch. É importante notar que o commit inicial de criação do branch, será visível apenas ao novo branch, mas não através do branch de origem (trunk). Desta forma, a partir do repositório de origem, não é possível determinar o momento exato de criação dos branches. 
    229  
    230 Após criado, o branch pode ser acessado de duas formas: 
    231 {{{ 
    232   svn checkout https://svn.expressolivre.org/sandbox/workflow/branches/1001 
    233 }}} 
    234 para criar uma nova cópia local do repositório já em seu novo branch, ou: 
    235 {{{ 
    236   svn switch https://svn.expressolivre.org/sandbox/workflow/branches/1001 
    237 }}} 
    238 para mudar o branch de sua cópia local. Todos os commits subsequentes serão acessíveis apenas através do seu branch, devendo seguir o mesmo padrão das mensagens de commit adotados no restante do ambiente. 
     42 * [http://trac.expressolivre.org/milestone/Sandbox%20-%20Workflow Milestone Sandbox - Workflow] 
     43 * [wiki:WF/propostasmoduloworkflow Propostas para o Módulo Workflow] 
     44 * [wiki:WF/propostasmvcworkflow Propostas para o MVC do Workflow] 
     45 * [wiki:WF/utilizandobranches Comandos SVN úteis (inclui svn merge)]