Changes between Version 13 and Version 14 of WF/versaoexperimental

Timestamp:

12/21/09 15:40:54 (14 years ago)

Author:

viani

Comment:

--

WF/versaoexperimental

@@ -143 +143 @@
 
  * Criar um novo modelo de execução de atividades
-  * Criar uma classe base para execução de atividades, contendo métodos básicos como inicialização, finalização, cancelamento, execução, continuação de uma instância, execução de ajax, comunicação com o engine e outros que um estudo mais detalhado venha a revelar;
-  * O desenvolvedor irá criar uma classe para cada uma de suas atividades, que estenderá a superclasse e que contenha atributos do tipo objeto para as classes controller, model e view da atividade;
-  * Implementar um método run que possa ser executado para iniciar a atividade. Continuarão a existir as classes de controller e model da atividade, em separado. Continuarão a existir as classes basecontroller e basemodel;
-  * O desenvolvedor poderá sobrescrever os métodos de evento da superclasse: inicialização, finalização, cancelamento, transição. Em especial a transição pode servir ao desenvolvedor para obter o id da instância, após o encerramento de uma atividade start;
-  * Criar uma nova classe run_activity, que será responsável por instanciar a classe 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;
+  * 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.
+   * Usar uma função global para obter este objeto, de modo a garantir que somente o código da classe seja carregado;
   * 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;
+  * 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.
 
  * Criar uma camada de visualização
   * Criar componentes para os diversos elementos de formulário, como textarea, inputs, etc;
   * Implementar um componente container, que agrega componentes em uma mesma linha do template;
-  * Criar componente de ocultação e um array de botões submit;
+  * 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);
@@ -162 +166 @@
   * 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);
+  * 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).
@@ -188 +192 @@
 
  * 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