Propostas para o MVC do Workflow

• 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;
  • 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.

• 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 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.