Changes between Version 14 and Version 15 of WF/versaoexperimental

Timestamp:

12/21/09 16:54:36 (14 years ago)

Author:

rufino

Comment:

--

WF/versaoexperimental

@@ -147 +147 @@
    * 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.
-   * Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado;
+  * 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;
+  * 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);
-  * Esta camada será representada pela classe baseview, que terá atributos para os componentes adicionados ao objeto view;
   * 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;
@@ -168 +173 @@
   * 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;
-  * Executar a atividade com tratamento de exceções (try/catch).
 
  * 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. Caso não tenha erros irá chamar o método de validação em php, via ajax;
+  * 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;
@@ -194 +202 @@
 
  * Criar uma camada para mapeamento objeto-relacional
-  * Considerar a experiência do Serpro-BA com o Propel
+  * Considerar a experiência do Serpro-BA com o Propel.