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