| | 1 | == Propostas para o MVC do Workflow == |
| | 2 | |
| | 3 | * Definir uma nova estrutura de diretórios para os processos |
| | 4 | * Considerar a experiência do Serpro-BA; |
| | 5 | * Analisar a estrutura de outros frameworks como o Cake e Simphony; |
| | 6 | * Prever áreas para: |
| | 7 | * Model-View-Controller; |
| | 8 | * Ajax; |
| | 9 | * Templates; |
| | 10 | * Js; |
| | 11 | * Imagens; |
| | 12 | * Jobs; |
| | 13 | * Classes de Negócio; |
| | 14 | * Config; |
| | 15 | * Facade (opcional); |
| | 16 | * Dao; |
| | 17 | * Serviços |
| | 18 | * Log. |
| | 19 | * 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; |
| | 20 | * Substituir a função wf_include por factory. |
| | 21 | |
| | 22 | * Criar um novo modelo de execução de atividades |
| | 23 | * Suprimir o arquivo php da atividade; |
| | 24 | * Dividir a atividade em model-view-controller |
| | 25 | * 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; |
| | 26 | * A classe da atividade deverá implementar os métodos que forem necessários; |
| | 27 | * Criar uma nova classe run_activity, que será responsável por instanciar a classe controller da atividade e executá-la; |
| | 28 | * Impedir que a controller tenha acesso aos atributos e métodos da run_activity; |
| | 29 | * Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado; |
| | 30 | * Testar se é seguro incluir o código da controller diretamente na run_activity; |
| | 31 | * 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; |
| | 32 | * Acomodar os processamentos pré e pós execução das atividades (agente de correio) em outro local do código; |
| | 33 | * Criar plugins para processos; |
| | 34 | * Transformar a conexão mainframe da Celepar em um plugin; |
| | 35 | * Tranformar a factory do processo em estática |
| | 36 | * Instanciar os objetos hoje pré-carregados, sob demanda; |
| | 37 | * Eliminar a código compilado; |
| | 38 | * Pensar se é viável liberar para o processo gravar dados na sessão; |
| | 39 | * Prover uma maneira do workflow diferenciar o código do mvc antigo e do novo e executar corretamente cada ambiente. |
| | 40 | * Executar a atividade com tratamento de exceções (try/catch). |
| | 41 | |
| | 42 | * Criar uma camada de visualização |
| | 43 | * Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc; |
| | 44 | * Prever inclusão da validação do componente; |
| | 45 | * Implementar um componente container, que agrega componentes em uma mesma linha do template; |
| | 46 | * Criar componente de ocultação; |
| | 47 | * Criar um controle de acesso por componente, para ocultar elementos que não estejam disponíveis para um usuário; |
| | 48 | * Prever também o encapsulamento dos plugins smarty criados para o workflow (select users, etc); |
| | 49 | * Carregar no template os arquivos javascript indicados pelo desenvolvedor. Possibilitar associar funções javascript aos componentes; |
| | 50 | * O objeto view deverá carregar os dados preparados na camada model e mesclar no template; |
| | 51 | * A criação do objeto smarty ficará ao encargo da camada view; |
| | 52 | * Criar uma função Js (goAjax) padrão para criar o objeto !NanoController e adicionar a chamada virtual (addVirtualRequest); |
| | 53 | * Simplificar os arquivos css e usar div ao invés de tabelas; |
| | 54 | * Pensar na possibilidade de aproveitar os frameworks de css 960 ( http://960.gs) e blueprint ( http://www.blueprintcss.org) na camada de visualização. |
| | 55 | |
| | 56 | * Tratamento e exibição de erros |
| | 57 | * O submit fará uma chamada ao dispatch: |
| | 58 | * O dispatch fará a verificação prévia de campos obrigatórios (1o. passo); |
| | 59 | * Caso não tenha erros fará a validação dos componentes, via ajax (2o. passo); |
| | 60 | * Caso não tenha erros irá chamar o método de validação em php, via ajax (3o. passo); |
| | 61 | * O método de validação php terá um nome padrão e será responsável por validações de negócio; |
| | 62 | * Caso existam erros na validação ajax, será polulado um array Js para exibição das mensagens no template (prever uma área para mensagens); |
| | 63 | * Caso sem erros, será montado o array request na model e feita a submissão. Validar novamente pela model php; |
| | 64 | * 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; |
| | 65 | * Incluir no template padrão uma função Js para exibir os erros encontrados. |
| | 66 | |
| | 67 | * Camada Model |
| | 68 | * Criar métodos para verificação de segurança sobre dados entrados pelo usuário: sqlinjection, xss; |
| | 69 | * Avaliar o htmlpurify e as soluções já utilizadas na run_activity e personalizadas nos processos já desenvolvidos; |
| | 70 | * Revisar e padronizar as classes utilitárias: tratamento de datas, expressões regulares, tipos de dados; |
| | 71 | * Incluir tratamento de erros na classe wf_db. Atualmente o workflow delega esta ação para o desenvolvedor; |
| | 72 | * Retornar o erro produzido pelo adodb ou o resultado da operação (resultset); |
| | 73 | * Criar automação de relatório genérico com a classe fpdf; |
| | 74 | |
| | 75 | * Criar uma biblioteca Js para funções úteis para os processos que não existam nas biblioteca de terceiros acessíveis pelo workflow. |
| | 76 | |
| | 77 | * Criar um local para definição das constantes do processo |
| | 78 | * Utilizado para array de mensagens; |
| | 79 | * Constantes operacionais; |
| | 80 | * Schema de banco de dados; |
| | 81 | * Qualquer outro parâmetro de configuração global do processso que seja necessário. |
| | 82 | * 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; |
| | 83 | |
| | 84 | * Padronizar os índices do array Requests com um prefixo, para facilitar a transferência entre as camadas; |
| | 85 | |
| | 86 | * Criar uma camada para mapeamento objeto-relacional |
| | 87 | * Considerar a experiência do Serpro-BA com o Propel. |
